Apparatus, device and method for prescribing, administering and monitoring a treatment regimen for a patient

ABSTRACT

A treatment Device is provided which enables a Doctor/Pharmacist to provide patient specific instructions in a textual format to a patient. The instructions are converted by a speech synthesizer provided in the Device into an audibly perceptible format. When configured as a hand-held unit, the Device may store a plurality of medications. Upon activation or automatically, instructions saved in the device are communicated to a patient/user via various audible, visual and/or tactile indicators. The instructions are provided to the device via a Platform which enables Doctors and Pharmacists input instructions into the Platform, which, via a Platform interface, are saved into a storage device provided in the Device. In an additional embodiment, a removable medication dispensing cartridge is provided which facilitates the controlled and automatic dispensing of a medication to a patient based upon a treatment schedule. Patient compliance information with a treatment schedule may be provided by the Device.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of co-pending U.S. applicationSer. No. 10/142,310 filed on May 8, 2002 and entitled “Apparatus, Deviceand Method For Prescribing, Administering and Monitoring a TreatmentRegimen For a Patient”, which claims the benefit under 35 U.S.C. §119(e) to U.S. Provisional Application No. 60/290,271 filed on May 11,2001 by Craig Shillingburg and entitled “Process and System forPrescribing, Administering, Administering and Monitoring a TreatmentRegimen for a Patient”, the contents of which are incorporated herein byreference in their entireties.

TECHNICAL FIELD

The technical field in which various embodiments of the presentinvention are described relates generally to the field of medicaltreatment compliance programs and more specifically to the field ofsystems and methodologies for determining and monitoring treatmentregimens for patients. Additionally, the technical field includessystems and/or processes for monitoring the compliance of patients withtreatment regimens, which may include prescribed medications.

BACKGROUND OF THE INVENTION

It is well documented in clinical studies that approximately 50% of theambulatory patients in the United States have difficulty remembering howand when to take their medications or comply with various treatmentregimens (for example, fasting, exercise and dietary constraints).Complex treatment regimens, chronic diseases, physical or mentalimpairments, discipline problems, lack of pain, busy schedules, and ageall contribute to noncompliance with prescribed therapies in homes andoffices. In group settings, such as long-term care facilities, hospitalsand nursing homes, additional compliance problems are caused by dosageerrors, accurate and timely distribution of medications, and adherenceto the particular regimen instructions. These occur because shortages ofqualified nurses or caregivers are faced with an ever larger group ofpatients and an increasing count of corresponding medications andtreatment regimens. Further, with the aging of the baby boom and theshortage of caregivers, it is anticipated that efforts to monitor thecompliance of patients with treatment regimens will become ever moreproblematic.

Additionally, it is commonly known and appreciated that manyprescription drugs or health aids, such as vitamins and healthsupplements, have specific ingestion requirements to ensure theireffectiveness or minimize unnecessary side effects. These include, butare not limited to, taking the medication before or after a meal, withor without liquids, not in conjunction with certain drugs or alcoholusage, if pregnant, before or after menopause, and whether dependentupon a status of injury or presence of a chronic disease. The need tocommunicate accurate instructions for each specific medication becomeseven more important when the patient is required to take more than onemedication, vitamin, supplement, meal, or treatment regimen multipletimes each day with a varying schedule and changes in dosage, frequency,and other variables.

Also, patients are often provided instructions for treatment regimens byvarious medical professionals and caregivers. Such professionals andcaregivers include, but are not limited to, doctors, nurses, medicaltechnicians, physical therapists, and dieticians. Throughout thisdisclosure (for purposes of simplicity) such professionals andcaregivers are commonly referred to as “Doctors”. Those skilled in theart appreciate the various legal and regulatory limitations placed uponindividual caregivers, and the use of the term “Doctors” is not to beconstrued as limiting the present invention to persons holding advanceddegrees in medicine or any other level of certification or licensing.Similarly, those responsible for dispensing or providing controlledmedications commonly are pharmacists. However, doctors and nursepractitioners often provide samples to patients which are not dispensedthrough a pharmacy. For purposes of simplicity, a person dispensing amedication to a patient which the patient may administer to themselvesor have administered to them (for example, with the aid of a nurse orother assistant) shall herein be collectively referred to as a“Pharmacist”.

Currently, two standard methods are often used by Doctors to instructpatients on treatment regimens and specifically on how to takemedications properly. One of these methods utilizes written and/orverbal instructions which pertain to a specific treatment regimen andare communicated by the Doctor directly or indirectly to the patient.Such instructions are often communicated in person, at a Doctor'soffice, however, remote instructions (including those via telephone,video links, facsimile, e-mail and other communications links) are alsoutilized. As is well known in the art, patients often misconstrue theinstructions communicated by a Doctor because the patient is in painduring the visit, gets confused by the technical explanations, havecomprehension difficulties, can not remember the precise instructions,are unable to read the Doctor's handwriting, and/or for various otherreasons. Further, many medication and treatment regimens are time and/orsequence specific and/or require non-medication treatment regimens to beperformed in order for the medication to be effective. In suchcircumstances, medication and/or treatment regimens may not be readilyavailable to the patient at the preferred treatment time(s).Additionally, those assisting a patient in taking medications (forexample, a son or daughter of an elderly person) are often not presentwhen the Doctor communicates the treatment instructions and thus may notbe fully informed of the recommended treatment regimen.

Further complicating the prescribing, administering and monitoring oftreatment regimens for a patient is the fact that Doctors andPharmacists often utilize inefficient and ineffective communicationmethods. Many persons are familiar with the practically illegiblescripts Doctors commonly utilize to prescribe medications. In fact, itis commonly appreciated that there is a need for effective communicationlinks between Doctors, patients, attendees, Pharmacists and othersassociated with treating patients.

Further, provided that proper consent and authorization has beenprovided, Doctors, Pharmacists and others often need to safely andsecurely share pertinent and secure information about a patient.Doctors, Pharmacists and others often need to also exchange currentmedical research data on diseases, impairments, medications or therapiesand other information. Under current practices, Doctors and Pharmacistsoften must rely on the patient to furnish accurate and completeinformation regarding their medications, health supplements, andcompliance history. Patients have to often provide this information(often collected in the form of a checklist followed by oral questions)because the means for a common electronic transfer system are not inplace. The reasons often cited for this lack of a common electronictransfer systems include the lack of a unified software platform,equipment compatibility, and costly subscriptions fees. Consequently,Doctors and Pharmacists often are not fully appraised of a patient'scondition. Referred Doctors (e.g., an orthopedic specialist), who maynot be approved by the patient's insurance carrier or practices outsidea specified health maintenance or preferred provider organization, oftenwill not receive a complete patient profile which is needed to make aninformed diagnosis and prescribe an effective and safe (when possible)treatment regimen.

A similar need exists to link medical professionals with currentresearch information on diseases, impairments, medications or therapiesfrom independent companies at an affordable cost. Many Doctors andPharmacists rely on medical journals, independent research, paidsubscriptions and promotional materials supplied by manufacturerrepresentatives to stay current with the ever-changing medical field.This is a timely and expensive process that can become overwhelminggiven the increasing patient load commonly being seen and cared for bytoday's Doctors.

Further, the number of medications taken by a patient can vary from noneto several dozen or more depending on age, the type or stage of aparticular disease, physical or mental impairments, and the occurrenceof a new injury or accident. Each medication typically has its ownspecific regimen (which should be followed to avoid unnecessarycomplications and/or undesired side effects) and comes in a variety ofsizes, shapes and unit counts. Consequently, the need exists for abase-operating platform that can be used, in one or more devices sizedto accommodate the different dispensing needs, to assist in theadministration of a given treatment regimen. Some individual patientsmay require a small, portable device or a table-top version for homeuse, whereas a long-term care facility may require a larger unit or asurface-mounted station to handle the needs of many patients.

It is also commonly appreciated in the medical community thatmedications can be extremely dangerous if taken improperly. Thus, a needexists for a device that is easy to use, is capable of providinginstructions for the treatment regimen, and contains a series ofredundant safety features that enables a patient, caregiver orthird-party individual to administer the taking of the medication inpre-selected doses at pre-determined times without having to receiveseparate instructions from a Doctor or Pharmacist. From the medicalprofessional's perspective, the interfacing software used to program thedevice is preferably easy to use and facilitates the efficient entry ofdata and instructions and the retrieval of compliance information.Further, such a device is desirably capable of being interactivelyprogrammed from a remote source.

Therefore, there is a need for a system and process which enables aDoctor to communicate patient information with other Doctors and/orPharmacists. Such a system also desirably enables the attending Doctorto efficiently determine whether a treatment regimen may becontra-indicated for a specific patient based upon patient information,general medical information, medication interaction information, andother information. The system also desirably enables a Doctor orPharmacist to monitor the patient's compliance with the prescribedtreatment regimen.

As mentioned previously, two methods are often used to communicate atreatment regimen to a patient. A second method often utilizesprescription labels attached to a pill-box or medication container (a“Container”) by a Pharmacist. Due to the limited space on a Container,these instructions are typically very brief or abbreviated. Morecomplete instructions, including warnings, side effects and instructionsfor taking the medication, may be provided in the retail or wholesalepackaging but are often printed in a very small font and discarded afterthe package is opened. Since patients often require the assistance ofothers to take their medications, the Container and associated packagingmaterials are often ineffective in properly and routinely notifying apatient or their caregiver about a treatment regimen. Further, suchContainers commonly do not provide a reliable mechanism for monitoringcompliance by the patient with a treatment regimen.

Currently, there are several electronic alarm devices available whichare designed to help patients determine when medications should betaken. While such devices are generally effective at providing audiblenotification signals, such devices do not provide the before mentionedand desired features and functions and generally have many shortcomings.For example, such devices usually do not properly address the problem ofinstructing a patient on how to take their medications. Nor do suchdevices enable Doctors and/or Pharmacists to program the device withcustomized instructions and related warnings which are automaticallyconverted into verbalized speech (when necessary) for communication tothe client. As such, commonly available devices hinder the accommodationof changing medications and treatment regimens. These devices also donot provide a system and process which verifies whether a treatmentregimen (which may include activities such as diet and exercise inaddition to medications) is appropriate for a patient and do not monitorthe compliance by the patient with such a regimen.

Another problem with current devices is the fact that third-partyassistance is often necessary to open a prescription container ororganize a patient's medications for a particular day, week or month,especially if a physical or mental impairment exists. This process canbe costly, inaccurate and time-consuming depending on the competency ofthe patient's caregiver. Presently, Pharmacists do not directly fillmedication organizers (i.e., containers for storing multiple medicationstaken by a patient on a regular basis) and, by law, are required to useonly pre-approved containers with childproof caps, unless grantedpermission by the primary care physician for an easy-open cap. Innursing homes, long-term care facilities, and similar locations, only aregistered nurse is allowed to sort the medications for dispensing tothe patients.

Existing childproof caps for prescription, non-prescription and healthsupplement containers commonly function by either a press-turn motion ora press-squeeze-turn motion. These caps can be extremely difficult toopen for the elderly and those with arthritis and coordinationimpairments. In moments of crisis, the problem is compounded by thetension and anxiety experienced by the patient. In addition, none of thecaps supplied by the Pharmacist can monitor the opening or closing ofthe container to determine if the patient is in compliance with theprescribed treatment regimen. Therefore, a device is needed which allowspatients to access medications with preferably little if any assistancewhile also allowing Doctors and/or Pharmacists to monitor compliance bythe patient with a treatment regimen.

SUMMARY

One embodiment of the present invention provides a system and processwhich facilitates the provisioning of specific and individualizedinstructions to a patient (or care provider thereof for a treatmentregimen. Additionally, the system provides for the verification that thetreatment regimen is safe and desirable for the patient, based upon thepatient's medical history and other information, while providing Doctorsand Pharmacists with patient compliance information which may be used tomodify and design the patient's current and future treatment regimen.Further, in this embodiment, a software program and/or a hardware devicemay be jointly or separately utilized to prescribe, verify, dispenseand/or monitor compliance by a patient with a treatment regimen whichmay include prescription medications.

More specifically, this embodiment of the present invention includes asoftware platform (hereafter, the “Platform”) which may be accessed bythe Doctors and Pharmacists to provide instructions on a treatmentregiment to the patient. The Platform may be utilized with a systemcompatible hardware device (hereinafter, the “Device”) which desirablycontains input/output elements for communicating information to apatient and others (such input/output elements may include, for example,lights, speakers and communications ports) and associated softwarecodes/programs which are used in controlling the various features andfunctions of the Device.

Further, in this embodiment, the Platform may be configured with aninterface which enables the Doctors/Pharmacists to program thesystem-integrated Device with a customizable treatment regimen. Thetreatment regimen may include, for example, verbalized instructions fora wide variety of patients and medical conditions over an extendedtreatment period. The Platform also may include interfaces which enableDoctors and Pharmacists to communicate over secure communication links.Such communications may include confidential patient information thatshould only be shared amongst authorized users. Examples ofcommunications links over which information may be communicated andexchanged between Doctors, Pharmacists and others include e-mailmessages, facsimile, instant messages or other communications link whichutilize secure network connections or secure information (e.g.,encrypted information) over non-secure network connections. Further,such information may be entered and transmitted via the Platformutilizing a menu-driven format that accepts typed, touch screen, stylist(for example, on a Palm® or similar Personal Data Assistant (PDA)),spoken or other modes for entering and/or transmitting information. Thisembodiment may also utilize customized or standardized input screens bywhich Doctors and Pharmacists may input communications or otherinformation. Such input screens desirably are easy to use and utilizecreative time saving actions, links, input fields and the like.

In order to maintain, update, program and refine the operation of thePlatform, other professionals besides Doctors and Pharmacists may beutilized. Such professionals include, but are not limited to, systemprogrammers, software and/or hardware engineers, and medical-relatedand/or insurance-related administrators. Throughout this disclosure (forpurposes of simplicity) such other professionals are commonly referredto as “Administrators”. The designation as Administrator may further bedefined based on security clearance to information stored on thePlatform or in associated databases. Such security clearance is createdusing methods including, but not limited to, access codes, accountnumbers, and user passwords that allow certain, pre-defined, segments ofthe Platform to be reviewed or modified. A low level security clearanceto stored information may refer to an Administrator such as an officeassistant, technical aid, nurse or caregiver who is responsible to enterbasic information about a given patient onto the Platform and may beallowed access to a limited number of screens or menus allowing aspecific function to be accomplished. A high level security clearance,which may include Doctors and Pharmacists, may provide full access tothe entire contents of the Platform including, but not limited to, thesource programming code.

Additionally, the Platform, in this embodiment and in other embodiments,may be configured to access external research data from third-partymedical information providers using commonly available communicationlinks, such as the Internet. Via such communications links, Doctors andPharmacists may receive automated program updates and access third-partymedical databases, which may contain the latest and/or recommendedtreatment regimens for almost any and all ailments and conditions. Suchinformation may be utilized by Doctors and Pharmacists in diagnosing andrecommending a treatment regimen, which may include prescriptionmedications.

Verbalized or typed data entries and menu keystrokes may also be used tointerface with the Platform and/or program the Device. One embodiment ofthe Platform may convert spoken or typed inputs into serially formatteddata that may be transmitted to a Device and/or stored in a locationaccessible by the Device. Additionally, at a plurality of predeterminedtimes specified by the treatment regimen, the controller in the Devicemay utilize internal software code to convert the digitized instructionsinto audible speech for playback over a loudspeaker. Alternatively, inanother embodiment, pre-recorded speech or other synthesized speechpatterns may be presented by the Device. The speech is preferablypresented in the order specified by a predetermined sequence, however,real-time determined speech patterns may also be presented. For example,for a given treatment regimen, a real time speech pattern (or othercommunication) may be presented to a patient. Such real-time speechpatterns may be based upon current conditions, compliance history and/orother variables.

Further, for at least one embodiment, the Platform provides thecapability of remotely programming the Device. When there is a need ordesire to change prescription dosages, the timing of medication ortreatment regimens or other configurations of a Device, Doctors andPharmacists can update the controls and operation of the Device via atelephone, the Internet or other communications links. Additionally, theinitial programming of the Device, for a specific patient, may also beaccomplished via a remote communications link or a direct communicationslink.

For at least one embodiment, the Device may also be configured togenerate sensory-based indicators which are designed to notify a patientwhen a treatment is needed, as specified by a given treatment regimen.The overlapping use, as desired, of visual, audio and tactile (e.g.vibration) alert mechanisms provide sensory output options which may betailored to patients, especially patients who suffer from physicalimpairments or cognitive deficiencies and who need an adaptable remindersystem. Additionally, the Device can be programmed to track each of aplurality of specific medications, the uniquely scheduled regimen forsuch medications, and the patient's compliance with such regimen.Further, the Device may be configured, as desired, to remind patients toperform certain other actions which may or may not be associated with agiven treatment regimen and which may or may not involve the taking of aprescribed medication. For example, the Device may be configured toremind a patient to drink a glass of milk one hour before taking arequired medication.

The Device may also be uniquely programmed by Doctors and Pharmacistssuch that those sensor indicators most effective for a particularpatient are utilized (for example, a deaf person might receive a visualand a tactile indication, whereas a blind person might receive anaudible and a tactile indication signal). The intensity, type andduration of such indication signals may also be suitably configureduniquely for each patient.

As such, various embodiments of the present invention fulfill the needfor a system and process which monitors compliance by a patient with aprescribed treatment regimen. The systems and processes discussed hereincombine an alert/notification system with corresponding instructions onwhat actions need to be taken at a specific time. Verbalizedinstructions (or written instructions, for example, when utilized by thehearing impaired) are preferably included in various embodiments of thesystem because such instructions provide patients with completeinformation about accomplishing their treatment regimen and provideadditional support in terms of time-sensitive reminders, reinforcementof the specific directions, patient encouragement, and related contactinformation.

These and other various embodiments of a process and system forprescribing, administering and monitoring a treatment regimen for apatient are further described herein with reference to the drawingfigures, the detailed description and the claims.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

FIG. 1 is a flow chart depicting the overall process flow by which onesystem embodiment of the present invention is utilized by a Doctor,Pharmacist, and/or patient to prescribe and monitor a treatmentregiment.

FIG. 2 is a schematic diagram depicting the various hardware componentsutilized in a system embodiment of the present invention.

FIG. 3 is a pictorial illustration of two configurations of a Devicewhich may be utilized in conjunction with various embodiments of thepresent invention.

FIG. 4 is a schematic block diagram of the functional componentsutilized in one embodiment of a Device.

FIG. 5 is a flow chart illustrating one embodiment of a process flow bywhich a Doctor and a Pharmacist may utilize the Platform and the Deviceto provide a treatment regimen to a patient and monitor the complianceby the patient with the treatment regimen.

FIG. 6 is a series of screen shots illustrating the interfaces providedby the Platform for one embodiment of the present invention.

FIG. 7 is a flow chart illustrating the process flow by which the Deviceoperates in its main control loop for at least one embodiment of thepresent invention.

FIG. 8 is a flow chart illustrating the process flow by which the Deviceloads a treatment regimen from the Platform into the Device for at leastone embodiment of the present invention.

FIG. 9 is a flow chart illustrating the process flow by which the Deviceprocesses a scheduled treatment regimen event for at least oneembodiment of the present invention.

FIG. 10 is a flow chart illustrating the process flow by which theDevice processes a button press occurrence for at least one embodimentof the present invention.

FIG. 11 is a flow chart illustrating the process flow by which a patientinteracts with the systems of at least one embodiment of the presentinvention to receive a treatment regimen.

FIG. 12 is a series of screen shots illustrating the interfaces providedby the Platform in another alternate embodiment of the presentinvention.

DETAILED DESCRIPTION

As mentioned previously, various embodiments of the present inventionprovide at least one process and/or system for diagnosing, prescribingand monitoring a patient's compliance with a treatment regimen. Morespecifically, in a first embodiment, a Doctor diagnosing a treatmentregimen to a patient may utilize the systems and processes describedherein to more accurately determine whether a diagnosis and contemplatedtreatment regimen is not contra-indicated for a specific patient basedupon a medical history, prior or current medications taken, how thepatient is presented, and/or other information and factors.Additionally, the Doctor may tailor the treatment regimen specificallyto the patient by providing verbal or visual instructions via a Deviceto the patient regardless of the time, date, or location of the patient(provided the Device is accessible to the patient at such times).Similarly, various embodiments of the present invention enablePharmacists to more accurately determine whether specific medicationsshould be safe to administer to a specific patient while also enablingthe Pharmacists to provide tailored instructions to such patients inlieu of, or in addition to, those instructions and/or informationprovided by a Doctor.

Referring now to FIGS. 1A and 1B, one embodiment of a process flow ofthe present invention is depicted. In this embodiment of the processflow, assistance is provided to the Doctor which enhances the Doctor'sability to quickly, efficiently, and/or accurately, diagnose a patient'scondition, prescribe a course of treatment, assess any risks associatedwith a prescribed treatment regimen (i.e., is a specific medication safefor a patient, and if not safe what risks or side-effects are associatedwith the contemplated treatment regimen). The process flow also enablesDoctors to generate instructions for the patient wherein theinstructions may be generic, semi-generic and/or uniquely tailored tothe patient and may be designed to assist the patient with complyingwith a treatment regimen. Such instructions may also specify how andwhen to monitor the patient's compliance with a given treatment regimenand/or provide other information to the patient, caregivers and others.

The role of Pharmacists, for one embodiment of the processes of thepresent invention, is also identified in the process flow of FIGS. 1Aand 1B. However, it is to be appreciated that, in certain situations, aPharmacist may not be involved in providing a treatment regimen to apatient. As such, FIGS. 1A and 1B encompass an omnibus view of thefeatures and functions of one embodiment of the present invention. It isto be appreciated, however, that various embodiments of the presentinvention may be simplified into its individual elements or combinationsof elements, as desired, without departing from the spirit or scope ofthe present invention.

As shown in FIGS. 1A and 1B, the present embodiment provides a processfor diagnosing a medical condition, prescribing a treatment regimen(which may or may not include a prescription medication regimen), andmonitoring the compliance by the patient with such treatment regimenpreferably. The process generally begins when a patient schedules anappointment with a Doctor (Block 102). At an appropriate timethereafter, the Doctor then conducts a review of the patient's medicalhistory and current condition, if any (Block 104). As is commonly known,the patient may or may not desire to share with the Doctor's assistantsthe purpose of the patient's visit. Additionally, for new patients, amedical history may not be available or accessible by the Doctor. Assuch, this embodiment of the process enables the Doctor to access andreview the patient's medical history and current needs, when available,but does not require such a review to occur prior to the Doctor visitingwith the patient.

Further, in certain situations (for example, a hospital emergency room),the scheduling of the appointment and the review of the patient'smedical history may occur real-time. In such situations, the Doctorattending to the patient may access the patient's medical information.Such access desirably occurs regardless of where the patient's medicalrecords are maintained and who is the patient's primary care physician.

Further, while patient's medical records are generally not kept in adata file that is accessible from a remote location, it is anticipatedthat such practices will become more common in the future. Additionally,while this embodiment of the present invention looks to the future forelectronically accessible medical records, it does not depend thereonfor its current or future application. As such, for this embodiment andother embodiments, it is envisioned that a process may be utilized bywhich Doctors are provided immediate access to patient's medicalrecords, when authorized. Further, such access may be accomplished viashared network databases, as explained further hereinbelow.

Referring still to FIG. 1A, the process continues with the Doctor“seeing” the patient, making an initial diagnosis, and deciding upon aninitial course of treatment (Block 106). It is commonly appreciated thata Doctor may “see” a patient in a multitude of ways including, but notlimited to: in person, via a videoconference link (or similar remotelinks), through an assistant, via a series of laboratory reports (forexample, a specialist who views recorded and/or real-time scans of thepatient but does not actually see the patient), and in other manners.Thus, the process is not limited by any specific temporal, procedural,or other requirements by which a Doctor “sees” or attends to a patient.Similarly, the diagnosis of a patient's medical condition and/or therecommendation of a treatment regimen may occur after one or morelaboratory tests, scans, patient visits, and other interactions by thepatient with the Doctor or other caregivers. As such, the process mayinvolve numerous repetitive instances of the Doctor “seeing” the patient(i.e., Block 106 may be repeated as necessary). Regardless of the type,number or frequency of visits, at some point the Doctor makes an initialdiagnosis of the patient's condition (as it is presented by the patientat a relevant time) and decides upon an initial course of treatment(which may include, for example, prescribing a medication and/orrecommending a treatment regimen).

A Doctor implementing this and other embodiments of the presentinvention may access a treatment clearance system. Access to thetreatment clearance system may be via any communications connection. TheDoctor may provide the patient's condition (i.e., how the patient“presents”), initial diagnosis, initial course of treatment and/or otherinformation to the treatment clearance system (Block 108). Suchinformation may also be provided by the Platform to a third partydatabase via customized pages and menu options provided by the Platform,as explained in greater detail herein.

The treatment clearance system provides those features, functions andexpert systems necessary to review a patient's medical history, currentcondition, and/or any other information provided by the Doctor. Thetreatment clearance system uses such information to confirm whether atreatment regimen is desirable for a given patient and/or to recommendan alternative treatment regimen. An example of a treatment clearancesystem which this embodiment utilizes, in whole or in part, is theUltiMedex® program provided by Micromedex®. The features, functions,capabilities, and interactivity of the UltiMedex® program are well knownin the art and are not described further herein. This embodiment of thepresent invention may utilize any and/or all of such features providedby the UltiMedex® program, or other programs, as desired.

Further, various expert systems exists, which are designed to assistDoctors in diagnosing medical conditions, recommending courses oftreatment for such conditions, recommending medications, and/orproviding information on side-effects, dosages, contra-indicators, andother information related to prescription medications, over-the-countermedications, alternative treatments, herbal treatments, and variousother forms of caring for a patient, may also be utilized, as desired.Using the present embodiment Doctors may utilize such programs alone orin conjunction with the UltiMedex® program. Also, Doctors may accessother third party databases, applications or programs as necessary.Further, the various system embodiments are not limited to any specificsystem components or configurations for verifying: whether a particulartreatment regimen is indicated or is contraindicated for a specificpatient; determining dosages or treatment regimens; or performing othertreatment related activities.

When utilized in a given embodiment and upon receiving the necessaryinformation (as dictated by the specific clearance program utilized andthe level of assistance requested by the Doctor), the treatmentclearance system provides an indication of whether a treatment iscontra-indicated or otherwise recommended for a patient, as identifiedto the system by the Platform and/or the Doctor (Blocks 110, 112 and113). When the treatment regimen is contra-indicated or otherwise notdesirable for the patient, the system suitably notifies the Doctor, whomay make any necessary or desired changes to the treatment regimen.Depending upon the desired levels of interaction provided by thetreatment clearance system, particular system embodiment capabilitiesand/or the Doctor's preferences, the clearance system may also beconfigured to recommend alternative treatment regimens. Such alternativetreatments may be recommended automatically, in all instances, only whena treatment is contra-indicated and/or in other situations (for example,when a medication preferred by the Doctor is not covered by thepatient's insurance provider, but a generic alternative is available).Further, a Doctor utilizing the Platform may also desire, in certainsituations, to bypass the treatment clearance system and rely upon theirown expertise and judgment. Various embodiments of the present inventionreadily support such desired and/or alternative practices.

At some point of the process, the Doctor desirably reaches a decision asto a recommended course of treatment for the patient. Such decision maybe reached with or without the assistance of the treatment clearancesystem. The Doctor confirms the treatment regimen to the Platform (Block114). At this instant, depending upon specific system embodiments and/orthe level of interactivity desired and/or specified between the treatingDoctor and other Doctors and/or Pharmacists, those Doctors andPharmacists who have access to the patient's medical records (either intheir entirety or in part) may obtain and/or be notified of the latestdiagnosis and treatment regimen for the patient. Such information may beextremely useful in providing the proper care to a patient, for example,by denying refill requests for medications earlier prescribed to thepatient.

Eventually, the Doctor communicates the treatment regimen to the patient(Block 116). The treatment regimen may include information andinstructions to the patient which go beyond the basic administering of aprescription medication. For example, an athlete who has undergone kneesurgery may be prescribed anti-inflammatory medications while also beingplaced on a strict physical therapy regimen. At least one embodiment ofthe present invention enables the Doctor to prescribe a treatmentregimen to the patient in any of numerous methods, including verbally,in writing, on a PDA or similar device, or even the Device, as describedfurther herein below. While the processes and systems discussed hereinare primarily directed to the administering and monitoring of thecompliance of a patient with a prescription medication treatmentregimen, it is to be appreciated that the Device (or a comparabledevice) may be suitably configured to encompass instructions andinformation on a non-prescription treatment regimen, such as, oneinvolving exercise, supplements, herbal remedies, and diet regimens.

Additionally, such treatment regimens may be updated in the Doctor'sdatabase for future reference by Doctors and/or Pharmacists as needed(Block 118). Thus, the systems and processes of the present inventionprovide the Doctors and Pharmacist with access to historical and/orcurrently prescribed treatment regimen(s) for a given patient (Block120). If a prescription is not part of the treatment regimen, theprocess may end (Block 121).

When the treatment regimen includes a prescription for a medication(Block 120), the process generally continues with the Doctorcommunicating the prescription to a Pharmacist (Block 122). Any currentor future methods for communicating a prescription to a Pharmacist maybe utilized including, but not limited to, written scrips, telephoneinstructions, facsimile, e-mail, the Internet, and direct wirelessconnections (for example, a Doctor may enter a prescription into a PDAwhich suitably communicates the prescription to a Pharmacist over awireless network). Preferably, the prescription communicated by theDoctor to the Pharmacist includes that information commonly provided ina written scrip including a designation of a type of medication, adosage, and a frequency. Additionally, the prescription message may alsoinclude a message containing customized instructions for the patient.Such customized instructions may be provided to the patient, via theDevice, at designated times and/or when desired, as discussed furtherhereinbelow.

When the patient receives a treatment regimen that includes aprescription for a medication, the patient may visit a Pharmacist toreceive the medication and/or a Device (Block 124). Since U.S. Food andDrug Administration regulations currently require many prescriptionmedications to be received in person by the patient or theirrepresentative, the process generally requires the patient/or theirrepresentative to actually travel to a pharmacy to receive theprescription medication. However, since foreign and/or U.S. laws andregulations often vary (or may vary in the future) on the dispensing ofprescription medications and other controlled substances, the variousembodiments of the present invention discussed herein are not to beconstrued as requiring the patient/representative to travel to apharmacy to receive a prescribed medication. As such, any current orfuture method for providing medications to a patient may be utilized.

As shown in FIG. 1B, when the medication/treatment regimen is providedby a Pharmacist, upon the patient arriving at the pharmacy thePharmacist may determine, preferably via a Pharmacist tailored versionof the Platform, whether the patient is a new patient (Block 126). For anew patient, the Pharmacist may enter patient identifying informationinto the Platform (Block 136). The Platform utilizes such information toobtain a patient's medical records from an accessible database (Block138) and/or to create a new patient record. In fully integrated systems(wherein the Doctors and Pharmacist utilize shared or commonlyaccessible databases) such patient information may include the mereentry of a patient identifier. In other applications, the patientinformation may include demographic information, medical information,and other information. Regardless of the precise implementation, it isto be appreciated that various methodologies exist by which a Pharmacistcan receive patient information. Such information can generally beobtained either directly from the patient or others, or viatelecommunications links with other systems and databases containingsuch patient information. For example, a database maintained by thepatient's primary care provider or insurance company (which isaccessible via the Internet) may be utilized, in one embodiment of thepresent invention, by an authorized Pharmacist upon entry of a uniquepatient identifier and a password. Thus, the various embodiments of thepresent invention may not be limited to any specific methodology forreceiving patient information and/or to any specific level of detailregarding such patient information.

Similarly, when the patient is not a new patient for the Pharmacist, thepatient's information may be verified by the Pharmacist using thePlatform (Block 128). The Platform may also be configured to query thePharmacist as to whether the patient has a Device to return (Block 130).This process step is generally performed whenever the patient isrequesting a refill. However, this step may also be performed wheneverthe patient has a new prescription.

If the patient has a Device to return, the Pharmacist accepts the deviceand may download statistics stored and/or compiled by the Device (Block132). These statistics may include compliance information for a giventreatment regimen. The downloaded information may be utilized forvarious purposes, for example, updating a patient's file that ismaintained in a database (Block 134). Such a file may be suitably usedby the treatment clearance system, when desired, to determine conflicts,contra-indicators and other tasks. More specifically, the Device may beconfigured, as desired, to compile various statistics on the patient'scompliance with a treatment regimen. In the first embodiment, suchstatistics are accessed when a refill or new prescription or treatmentregimen is to be fulfilled. However, the compliance information may alsobe accessed at any time, provided the Device is equipped with a wirelessor remote communications capability. Further, the first embodiment mayutilize the device compliance information in order to provideindications as to whether a medication or treatment regiment may becontra-indicated for a patient. Recommended dosage levels and otherinformation may also be provided.

Additionally, the compliance information may be used to generatestatistical information for a single or a plurality of users. Forexample, during a clinical study on the effectiveness of ananti-migraine medication, the Device may be utilized to determine howoften, how many, and at what times a patient taking the new medicationis compelled to take another pill. Such information may be valuable, forexample, in determining future dosing regimes, the effectiveness of themedication, and other information.

As mentioned previously, the Pharmacist may access the Doctor's databaseto obtain the prescribed treatment regimen and/or verify the writtenprescription's validity (Block 138). In the first embodiment, suchverifications may be performed automatically, however, they may also beperformed verbally, via fax with the Doctor's office, and in othermanners. Further, when a Device is returned by the patient, thePharmacist may also provide the previously downloaded patient complianceinformation to the Doctor's database while also reviewing the record forany warnings on prescriptions or other treatment regimens (Block 140).This feature is basically designed to prevent or discourage a patientfrom “shopping” for a Doctor that will prescribe a medication that iscontra-indicated for the patient, but may also be used, for example, toreduce the occurrence of an emergency room or other Doctor prescribing amedication that is contra-indicated for the patient.

Further, the process may determine whether any complications exist(Block 142). The Pharmacist may also be provided with sufficientinformation about the new treatment regimen, contra-indicators (if any),and other variables to make a determination real-time as to whether itis safe and/or recommended to provide a medication to a patient. Inunclear situations, a consultation with the prescribing Doctor and/orthe patient's primary care physician may be necessary. Further, sincethe prescribing Doctor may not have been fully or accurately appraisedby the patient about a current or past treatment regimen or medicalcondition, this process preferably provides a second check and enablesthe Pharmacist and/or the Doctor to verify the parameters for the newcourse of treatment. This process may also be configured to providenotifications and/or warnings to the Pharmacist about complianceproblems, drug or treatment contra-indicators, and/or other patientspecific information.

For example, utilizing at least one embodiment of the present invention,when a patient is diagnosed with a bacterial infection it is commoncourse of treatment to prescribe a first anti-biotic. When the patientfails to take the first anti-biotic to completion and ends up visitingthe Doctor with a worse infection, the Device enables the Doctor and/orthe Pharmacist to verify that the patient actually opened the Device(and presumptively took a pill) in accordance with the prescribedtreatment program. Further, when the desired level of compliance is notachieved, the Doctor and Pharmacist may be appraised of the fact thatthe patient had difficultly complying with the treatment regiment anddid not take all of the medications per the designated schedule. Basedupon this and/or other information, the Doctor may decide to prescribe ahigher dosage, a shorter treatment cycle or perform other actions, suchas creating a reminder message to the patient, which is delivered viathe Device, about the importance of taking antibiotics according to aprescribed treatment regimen. Thus, at this point of the process, thePharmacist may be appraised of the new treatment regimen and, when aDevice is returned, past compliance with previous treatment regimens.

Further, when a new treatment regimen or the patient's compliance with aprevious treatment regimen are problematic, for whatever reasons (forexample, adverse drug interactions or the patient's failure to completea required first drug regimen before commencing on a second drugregimen), the Pharmacists and/or the Platform may be configured tonotify the Doctor of the conflict and/or complications (Block 143).These notifications may occur automatically or upon the Pharmacist'sdirection, via any desired means of communication including, but notlimited to, an electronic message over a shared system or database, ane-mail, a telephone call, and a page. The process then continues, forthis embodiment, with the Doctor selecting an alternative treatmentregimen, when so desired (Block 113).

When complications are not found, the Pharmacist may verify theprescribed treatment regimen is correct (Block 144) and may dispense themedication/treatment regimen to the patient. Such dispensing may includeproviding medications via the Device. More specifically, the Pharmacistmay fill or insert medications into the dispensing Device. Verificationthat the Device will operate in accordance with the prescribed treatmentregimen (Block 146) may also be accomplished. Further, since the Device,in certain embodiments, may be configured to receive and presentcustomized audible instructions (and in certain embodiments with visualinstructions) and/or automatically dispense medications (as provided forin an alternative embodiment discussed below), the Pharmacist alsopreferably verifies that the dispensing Device operates correctly beforeproviding the Device to the patient (Block 148). The Pharmacist may alsoprovide an update to the Doctor's database or the patient's informationfile that the patient has received the prescribed medication and/ortreatment regimen information (Block 150). The process suitably ends(Block 152).

At this stage of the process, the patient has been provided with aDevice for dispensing a medication. Various embodiments of the Devicemay provide, for example, upon the pushing of a button, informationand/or instructions relating to a treatment regimen. Compliance withsuch instructions and treatment regimen may be monitored by the Device.Further, in certain wireless embodiments, verifications of Deviceoperation and compliance information may be obtained via remotecommunications links.

As shown in FIG. 2, an embodiment of a system 200 for implementing thepresent invention includes the Platform 202, a Doctor/Platform interface204, a patient Device 206, and a third party database 208. Each of theseelements may be connected, for example, via the Internet 220, directconnections, or via any other communications link. Various types andconfigurations of communications link and/or systems may be utilizedincluding, but not limited to, fiber optics, twisted pair wire,telephone circuits, Ethernets, intranet, wide area network connections,local area network connections, cable, satellite, and wirelessconnections.

Also, the data throughput may be provided at any data rates available.For the present embodiment, such communications links preferably utilizeDigital Subscriber Links, T-1 links, or other high data throughputcommunications links, in order to minimize the amount of time necessaryto communicate information between the Platform 202, the Doctor/PlatformInterfaces 204, and the 3^(rd) party databases 208. Similarly, theclient device 206 may be configured with a high speed data port, but asconfigured for the present embodiment, such data throughput capabilitiesare not needed nor the communications interfaces desired.

As mentioned previously, the Platform 202 may be further subdivided, asdesired, into a Doctor's system 214 and a Pharmacist's system 216. Suchsystems 214 and 216 may be implemented on any suitable device includinga network server, a computer workstation, a distributed system, aself-contained system, a personal computer, a micro-computer, a mainframe computer, a PDA with wired or wireless communication capabilities,or any other similarly capable system or device. Further, while depictedin FIG. 2 as encompassing a single Platform containing both the Doctor'ssystem 214 and the Pharmacists system 216, either system (Doctor's orPharmacists) may be implemented independently of the other. However, inthe preferred embodiment, a single Platform that is accessible bynumerous Doctors and Pharmacists may be utilized, thereby minimizingdata file sharing conflicts, communications delays and otherconstraints. Regardless of the specific implementation, the Platform issystem and device indiscriminate and may be implemented, as desired andas particular needs dictate, on any device or system capable ofperforming the features and functions identified herein.

The Doctor/Platform interface 204, as shown, may also be provided on anyof a variety of devices, provided such devices are capable of accessingthe Platform and communicating the necessary information between theDoctor and the Platform. Various communication networks may be utilizedto connect the Doctor with the Platform, the Device (via, for example,an Internet connection), and/or 3^(rd) party database(s) 208. Oneexample of such an interface 204 is a lap top computer 210 (or desk topcomputer) utilized as a Doctor's data terminal. It is to be appreciatedthat a plurality of computers (lap top and/or desk top) may be suitablyinterconnected via wired and/or wireless networks. As such, a Doctor'soffice, hospital, or other facility may contain a sufficient number ofreadily accessible terminals (for example, one at each nursing station)via which the systems and processes of the present invention may beutilized. Similarly, a PDA 212 with a remote communications capabilitymay be utilized to communicate information between the Doctor, thePlatform, the Device, and/or the 3^(rd) party databases 208. In thepreferred embodiment, wireless equipped PDA's 212 may be utilized by theDoctor to interface with the Platform 202. Further, the PDAs 212 may bevoice activated and, thereby, enable the Doctor to communicate with thePlatform 202 as if the Doctor is dictating or providing directions to anurse or other assistant.

Similarly, the 3^(rd) party databases 208 may be suitably configured assystem complexities and individual applications of various embodimentsof the present invention dictate. As such, the 3^(rd) party database 208may include a comprehensive treatment clearance system 218, such as theUltiMedex® system, and/or may include individual elements, which mayperform specific tasks. Further, the 3rd party databases 208 may includeinformation provided by any source including, for example, the Food andDrug Administration, the American Medical Association, drug companies(e.g., Pfizer®, Merck®, and Glaxco-Wellcom®, independent laboratories,chemical manufacturers, and any other treatment related informationaccessible over the Internet or any other communications link andprovided in a format accessible by the Platform 202. Preferably, suchinformation may be provided in an electronic format, however, other dataformats may also be used, especially data formats used or supported byadvanced computing systems and especially by artificial intelligence orexpert systems.

Various embodiments of the Device 206 are further explained withreference to FIG. 3A, FIG. 3B, and FIG. 3D. As discussed previously, theDevice 260 may be provided in a portable, pager sized, configurationsuch that a patient may easily transport the Device, for example, in acoat or pants pocket. However, larger versions of the Device 206 mayalso be utilized including devices capable of dispensing numerousmedications and/or standalone devices utilized, for example, by a nurseto administer to a person on bed rest. Therefore, the Device 206 is notlimited to any specific application, size, shape or configuration andmay be utilized in various embodiments and configurations.

Referring now to FIG. 3A and FIG. 3B, two embodiments of the Device 300and 302 are shown. For a first embodiment, a smaller, pager sized Device300, as shown in FIG. 3A, may be utilized. It is anticipated that aDevice 300 of such size and configuration is convenient to use andtransport, while also being capable of storing a sufficient quantity ofa given medication. While the embodiment shown in FIG. 3A is preferablyconfigured to dispense a single medication. Another embodiment of theDevice 302, which may be used and configured to dispense multiplemedications, is shown in FIG. 3B.

Regardless of the size, shape, configuration or number of medicationsdispensed, the Device may include at least one internal chamber 304 forstoring the medication. In the single medication dispensing embodiment,as shown in FIG. 3A, only a single chamber 304 is provided. In themultiple medication dispensing embodiment, as shown in FIG. 3B, threechambers 304 are provided. Further, it is to be appreciated that achamber may be configured in any size and shape and is not limited to avertical, tubular configuration, as shown in FIG. 3A and FIG. 3B.Additionally, any number of chambers may be provided in the Device withappropriate tradeoffs occurring in the size, shape and weight of theDevice. Further, alternative embodiments of the Device may not includeany chambers. Such a configuration may be utilized when non-medicationbased treatment regimens are prescribed or medications cannot be safelyor effectively stored in the Device.

In general, the FDA currently allows medications to only be dispensed inapproved pill containers which can not be recycled. To accommodate theseand other regulations, the chamber 304 may be configured such that itaccepts and suitably retains a disposable sleeve or other approved pillcontainer (not shown) for storing the medications. In such anembodiment, the sleeve may be slid into the chamber 304 by thePharmacist at the time of dispensing the medication and may be removedupon subsequent use or refilling of the Device. For medications which donot require a prescription (for example, aspirin), a generic and/ordisposable sleeve may also be used as needed and/or desired.Additionally, in the multi-medication per chamber embodiment, thesleeves may be configured to hold multiple medications as needed.

Further, the Device may be configured with various opening caps whichrestrict and allow access to the medication in the chamber 304. As shownin FIG. 3A, one embodiment of a cap utilizes a sliding top opener 306and may include an internal locking mechanism which prevents accidentalspilling of the medication and/or non-timely access to the medication.Another embodiment is shown in FIG. 3B wherein a tab opener 308 isprovided in the cap. Additionally, sensors 324 may be provided in orderto determine when the cap (e.g., the sliding top opener 306 or the tabopener 308) is opened. These sensors may also be used to facilitate thecollection of compliance information for a treatment regimen. Further, asolenoid locking mechanism 326 may be included in the Device in order toprevent non-timely and/or unauthorized access to the medicationscontained within a chamber 304. While the embodiments of FIG. 3A and/orFIG. 3B, include a sliding opener 306 and a tab opener, respectively, itis to be appreciated that various other caps/openers including, forexample, a pop-top, a twist top, a child proof top or other caps/openersmay be utilized in the Device. Further such caps may be equipped withcap sensors 324 and/or cap solenoids 326. Additionally, in the multiplesleeve per chamber embodiment, additional opening tabs (both internaland external) may be provided. Such tabs may also be configured to allowaccess to only specific medications at specific times, for example, asdictated by a treatment regimen.

The Device 300 may also include Light Emitting Diodes (LEDs) 310, whichmay provide visual indicators of the various operating states of theDevice. While the embodiment shown in FIG. 3A includes LEDs 310, inalternative embodiment a Liquid Crystal Display (LCD) 312 (as shown inFIG. 3B) or similar displays may be utilized. Such similar displays mayinclude incandescent, fluorescent, neon or other visual display devices.Further, certain embodiments of the Device may not include any visualdisplay capabilities. The Device 300/302 may also include a slot 314into which a Pharmacist may insert a name of the medication(s) and/orthe prescription treatment regimen(s). In at least one alternativeembodiment, such information may also be suitably presented to thepatient via a label which may be adhesively attached to the Device.

The Device may also include a speaker 316 by which audible messages andindicator signals may be presented to the patient. Such messages andindicator signals may be presented in accordance with a treatmentregimen programmed by the Doctor and/or the Pharmacist and/or based uponother variables (some of which may be set by the patient). While aspeaker is preferably utilized, head-phones may also be utilized via ahead-phone jack 328. As is discussed further below, such messages andstatus indicators may be retrieved by the patient at any time byselection of the appropriate buttons. Further, the Device 300/302 mayalso include a “Talk” button 318, which by using the appropriateselecting sequence (as described below), enables the patient to directthe Device to provide various status and treatment messages. For a firstembodiment, a single Talk button 318 is provided. However, otherembodiments may utilize other user input interfaces including, but notlimited to, volume controls, alphanumeric keypads, voice command systemsand/or additional buttons.

Further, the Device may also include a Platform interface. The Platforminterface allows the Pharmacist and/or the Doctor to receive complianceinformation and/or program the Device via a docking station or otherinterface with the Platform. For one embodiment, a data port 320functions as the Platform interface in order to facilitatebi-directional communications between the Platform and the Device. Forother embodiments, other adaptors and/or ports may also be utilized as aPlatform interface, such interfaces include, but are not limited to, aserial port, a parallel port, infrared, RF, IrDA, Blue Tooth, wireless,a Universal Serial Bus (USB) port, an Ethernet port, an RS-232 port, anda telephone data port. Thus, for various embodiments of the presentinvention, interconnectivity between the Device and the Platform may beprovided via a wired or wireless communications system. Examples ofwireless communications systems include, but are not limited to, pagingsystems, digital or PCS systems, cellular systems, infrared systems,and/or radio frequency systems.

Similarly, a smart card reader 322 (FIG. 3B) may also be utilized as analternative Platform interface port. FIG. 3C provides on example of asmart card 330 which may be utilized in conjunction with variousembodiments of the present invention to provide a portable and securedevice for transporting prescription or other treatment information froma Doctor to a Pharmacist and/or another Doctor. As shown, the smart card330 includes an embedded computer chip 332 which contains those desiredprocessing and data storage capabilities. The computer chip 332 may beconnected to a series of leads 334 by which the smart card 330communicates with a reader. The card 330 may be made out of alightweight, yet durable materials, such as plastic, and may beconfigured such that it is easy to transport and utilize, for example,by including a magnetic strip or stamp (not shown). The smart card 330may be programmed by a smart card programmer or similar apparatus.

In another embodiment, the Device may also be configured with anautomatic medication (pill) dispensing device. As shown in thecross-sectional view of FIG. 3D, this embodiment of the Device 336includes locations for mounting a printed circuit card 338 which holdsthe processor and other components which control the features andfunctions of the present invention and are described in greater detailbelow and with reference to FIG. 4A and FIG. 4B. Additionally, thisDevice 336 may include at least one internal chamber 304 into which amedication dispensing cartridge 340 may be inserted.

Various embodiments of a medication dispensing cartridge 340 are shownin FIGS. 3E, 3F, and 3G. With particular reference to FIGS. 3D and 3E,the cartridge 340 may contain sufficient space to store multipleinstances of a pill 342 (not shown in FIG. 3E). A platform 344 restingon a spring 346 is provided at one end of the cartridge 340 so as toprovide an upward force upon any medications inserted into the cartridge340. The cartridge 340 may also include a top lid 348 which may beattached to the sides of the cartridge 340, for example, via a hinge 350or may be otherwise suitably connected. It is to be appreciated,however, that the top lid 348 and hinge 350 may be removed orrepositioned on the cartridge as desired. For example, in the roundembodiment of a cartridge, as shown in FIG. 3G, a top lid and hinge arenot provided. Instead a screw mount, pressure seal mount or other typeof mount may be utilized to secure the cartridge after pills have beeninserted.

Referring again to FIGS. 3D and 3E, the cartridge 340 may also includean electrical connector 352. The electrical connector 352 may bepositioned on the cartridge 340 such that an opposite connector 354 onthe Device 336 may establish an electrical connection between thecartridge 340 and the Device 336. Information concerning the medicationcontained by the cartridge 340 is preferably communicated to the Device336 via the electrical connectors 352 and 354.

A first opening 356 and a second opening 358 may also be positioned nearthe top of the cartridge 340 so that a medication transferring device,for example, a probe 360 or other member, may be inserted through thefirst opening 356 (thereby making contact with a pill 342) and the pillis pushed through the second opening 358 into the holding chamber 362.The probe 360, for one embodiment, is activated by a motor and gear 364.The motor and gear 364 may also be utilized to provide a tactileindication to a patient that a time for receiving a treatment hasoccurred. The cartridge 340 may be suitably secured into the Device 336,for example, by a screw top 366 situated at the bottom of the Device336. As such, the operation of this alternative embodiment of a Device336 may utilize a spring loaded cartridge 340 and a probe 360 todispense a pill 342 from the cartridge 340 into a holding chamber 362from which the pill 342 may then be consumed by the patient. The holdingchamber 362 may be secured from the patient by a tab opener 306 or otheropening. Similarly, the cartridge 342 may be secured into the Device 336by a locking screw top 366 or other fastening means.

Additionally, the cartridge in certain embodiments 340 may be providedto the Pharmacist in a pre-loaded condition or an unloaded condition bya manufacturer of the medication to the Pharmacist. As shown in FIG. 3F,a safety seal 368 may be suitably attached to the cartridge 340 andremoved by the Pharmacist prior to insertion into the device.Alternative embodiments of a cartridge and automatic dispensingmechanism may also be provided including a gravity fed cartridge(instead of spring fed cartridge) and various other forms of removing apill from a cartridge.

Another embodiment of the Device of the present invention is shown inFIGS. 3H-3K. As shown in FIG. 3H, this embodiment of a Device 368provides multiple chambers 370 into which medications of various sizesand shapes may be inserted. Such medications may be suitably loaded intothe Device 368 by a Pharmacist upon removal of a top lid 372 which mayslide above, under and/or upon two rails 374 situated at the top of theDevice 368. When sliding the top lid 372 on the rails 374, the top lid372 may be secured into place via locking mechanism 376. The Device 368may also include a lower holding chamber 378 which may be suitablyaccessed by a patient or other user, for example, via sliding sideopener 381. The sliding side opener 381 may also include a lockingmechanism (not shown) which may prevent or limit patient access to thepatient accessible chamber 378 at improper times.

As shown in FIG. 31, which provides a cross-sectional view of the Device368 taken along the lines of A-A (of FIG. 3H) each of the chambers 370may be uniquely configured (based upon the size and configuration of agiven medication) to filter pills through the device and into thepatient accessible chamber 378. Additionally, each of the chambers 370may be configured without any filtering mechanisms and may insteadutilize customized sleeves that are inserted into the chambers 370. Inorder to control the dispensing of medications from the chambers 370 andinto the lower holding chamber 378, the Device may utilize, as amedication transferring device, a slide tray 380 (as shown in greaterdetail in FIG. 3K). The slide tray 380 may include preset openings 383that line up with openings 382 in the bottom of the chambers 370 (asshown in FIG. 3J, which is a cross-sectional view taken along the linesof B-B in FIG. 3) such that only a given quantity of pills are dispensedfrom the chambers 370 and into the lower holding chamber 378 at a giventime. The slide tray 380 may be manually or automatically operated. Assuch, this alternative embodiment provides a filtering mechanism andcontrolled dispensing mechanism for a multiple pill embodiment. It isanticipated that such an embodiment may be desirable for patients whoconsume numerous pills on a regular interval. The lower holding chamber378 may be utilized in various embodiments to limit patient access tomedications. Further, in certain embodiments, patients may not beallowed access the chambers 370 and may only have access to medicationthat has been dispensed into the lower holding chamber 378 in accordancewith a prescribed treatment regimen. It is to be appreciated, that suchaccess control features may be highly desirable for limiting access tomedications when patients are incapable, for whatever reason, ofresponsibly dispensing medication. Examples of such patients mayinclude, but are not limited to, children, addicts, those patientssuffering from various stages of dementia, and others.

Referring now to FIG. 4, a block diagram of the internal hardwarecomponents utilized to provide the features and functions of the Device,for at least one embodiment, is shown in conjunction with the externalhardware interfaces and components previously mentioned herein withreference to FIG. 3A and FIG. 3B. The internal hardware components mayalso be suitably utilized, in whole or in part, with the variousalternative embodiments shown in FIGS. 3C-3K or other embodiments notshown or discussed herein.

The operation and control of the Device may be accomplished utilizing amicroprocessor controller 400, for example a MicroChip Corporation 16C63controller. The controller 400 desirably provides on-chip input/outputand memory capacity, a local Universal Asynchronous ReceiverTransmitter, and flexible interface related instructions. However, othercontrollers and/or combinations of components may be utilized to controlthe operation of the Device.

The controller 400 may be suitably connected to the various, previouslyidentified, external hardware devices, such as the smart card reader322, Talk button 318, interface port 320, LEDs 310, cap sensors 324, capsolenoids 326 (when provided), and LCD 312. Such external hardwaredevices may be individually connected to the processor, connected via adata bus, via a multiplexed data signal, and in various otherconfigurations. Thus, various embodiments of the present invention mayutilize various techniques and components for connecting internal and/orexternal hardware devices to the controller 400.

The controller 400 may also be suitably connected to an internal clock402, which is preferably a Dallas DS 1205 time keeper chip. The DallasDS 1205 chip provides crystal based time keeping of seconds, minutes,hours, days and months. Other clocks or oscillators may also be utilizedby the controller 400 to control its internal timing and otheroperations.

In order to provide tactile sensory inputs, the Device may include avibrator motor 404. Preferably, a vibrator motor may be selected whichminimizes the space and energy needed for its operation, therebyallowing a reduction in the size of the Device and longer periods ofoperation without a recharge of the batteries or connection to anexternal power source.

A memory/storage device 406 may also be utilized by the controller 400to store operating instructions, program routines, textual instructionsfrom the Doctor and/or Pharmacists, patient compliance data, Deviceoperating data, and other data. In one embodiment, a Microchip 24L64 32Kbyte EEPROM memory chip is utilized to provide nonvolatile memory.However, other volatile and non-volatile memory may be utilizedincluding, but not limited to, other types of ROM, RAM, PROM, EEPROM,and EPROM. Additionally, data storage devices such as hard disc drives,micro-cassettes, digital tape, magnetic storage devices, optical storagedevices, memory sticks, memory cards, and various other devices may beutilized to provide data storage and retrieval capabilities.

Additionally, a Double Talk® RC8650 speech synthesizer 410 (from RCSystems®) may be provided with the Device. The Double Talk® speechsynthesizer may be utilized to provide direct translations of text tohigh quality voice speech synthesis. Such voice speech synthesiscapabilities enable the Device to be configured such that messages arepresented in a language native to the patient and/or an assistant to thepatient, while also being presentable in English. The Double Talk® chipset also provides numerous features including pitch and audio outputrate control and includes an internal memory for storing up to 130seconds of pre-recorded speech and sound effects. Additionally, theDouble Talk® chip set allows the processor 400 to send text basedmessages directly using simple handshake status controls to pace messagerequests over a 3-wire serial interface. Such text based messages mayalso be suitably converted into visually displayed messages, for examplemessages displayed on an LCD 312. While the Double Talk chip set ispreferred, it is to be appreciated that various other voice synthesischip sets or codes or text to speech offline and playback systems may beutilized to provide the desired text to speech translations.

Similarly, recent advances in software based text-to-speech systems,such as AT&T's® Natural Voices™ Text to Speech engine, have made itpossible to utilize software based applications and hardware basedapplications, to provide text-to-speech capabilities. As such, invarious embodiments, the Device may utilize speech synthesizers 410 thatutilize specific hardware, software and/or combinations thereof in orderto provide the beforementioned text-to-speech translation andcommunication capabilities.

Further, an audio amplifier 412 may be provided in the Device. Whenprovided, the audio amplifier 412 amplifies the output signal from thespeech synthesizer 410 and outputs a human renderable audio signal tothe speaker 316 and/or a head set (not shown) via the head set jack 328.

The Device may further include a battery monitor 408 which providespower monitoring and management functions. Based upon the power drainand utilization of the Device at any time, coded synthesizer basedmessaging may be provided in order to notify the patient (or other userof the Device) of service requirements such as replacing and/orrecharging a battery. The battery monitor may also utilize resources onthe controller to minimize the power consumption. Such power savingtechniques include powering down the speech synthesizer 410 and theaudio amplifier 412, as well the timekeeper chips 402. Further, thecontroller 400 can be configured to operate in a periodic power on modeand/or operate in a reduced power mode for the majority of the time(i.e., when the controller 400 is not called upon by the treatmentregimen to notify a patient that a medication is to be taken and/or atreatment regimen is to be performed).

As mentioned previously, in those embodiments in which a cartridge maybe utilized, the Device may also be equipped with a cartridge interface414. The interface 414 enables the Device to obtain information from acompatible cartridge including the type of medication contained in thecartridge and other information. In an alternative embodiment, thecartridge itself may be programmed with some or all of the desiredtreatment regimen information which may be provided to the Device viathe cartridge interface 414. It is anticipated that in variousembodiments prescription specific information may be pre-loaded into asuitable storage device on a cartridge. Such information may thenaccessed by the patient via the Device and the interface 414.

Referring now to FIG. 5 and FIGS. 6A-6T, a process flow chart and anexemplary series of screen shots are provided which illustrate how aDoctor and/or a Pharmacist interfaces with a first embodiment of thePlatform in order to prescribe a treatment regimen and verify theprescribed treatment is not contra-indicated for the patient. As shown,the exemplary series of screen shots are provided by the RxSure™program. However, other programs, screen shots, and process flows may beutilized without departing from the spirit or scope of the presentinvention.

As shown in FIG. 6A, the process by which a Doctor and/or a Pharmacists(and possibly a patient desiring to review their medical records)utilizes a Platform to prescribe and monitor compliance by a patientwith a treatment regimen suitably begins when a Doctor or Pharmacistaccesses the Logon Screen 600 (as shown in FIG. 6A). As shown in FIG. 5,this first operation is illustrated by the Start and Logon Systemoperation (Block 500). For at least one embodiment, the Platforminterfaces provided to Doctors and Pharmacists are substantially thesame, with access to the various features, functions, and informationbeing controlled by account numbers and passwords. It is anticipatedthat by providing a common interface, the Platform enhancescommunications and interaction between Doctors and Pharmacists. However,in various other embodiments, custom tailored interfaces may be utilizedby Doctors and/or Pharmacists. Such custom interfaces may be provided ona collective, group, or individual basis.

Referring again to FIG. 6A, the Logon Screen 600 may include an accountnumber field 601 and a password field 603. It is anticipated, in certainembodiments, that the Platform may be hosted on a networked server, alocal server, or similar configuration wherein numerous Doctors and/orPharmacists may access a centralized database to obtain patient andtreatment information. The account number and password may be used torestrict access by authorized users to the various features andfunctions of the Platform, as well as the databases utilized to storepatient information. Further, various other security systems may beutilized in conjunction with the Platform to control and restrict accessto patient information, medication information, and other features andfunctions provided by the Platform or accessible from various databasesaccessible via the Platform. Such security systems include, but are notlimited to, biomedical systems such as retinal scanners and voice orfingerprint recognition systems.

When the appropriate account number and password have been entered onthe Logon Screen 600 (when required), the Platform may determine whetherthe user is a Doctor or a Pharmacist (Block 502, FIG. 5) and providesthe appropriate levels of access to the databases, features andfunctions of the Platform based upon the type of user and/or the user'sidentity. Regardless of whether the user is a Doctor or a Pharmacist,the Platform, for this embodiment, is configured to present the PatientInformation screen 602 as shown in FIG. 6B. This screen 602 provides asummary field 604 and a detailed information field 606. The detailedinformation field 606 enables a user to access various screens byselecting one of the corresponding tabs 608, the functions of each tabare discussed further below.

Further, the summary field 604 may be configured to contain a set ofdata entry boxes 610 in which a patient's name may be suitably entered.In the preferred embodiment, existing patients are suitably identifiedby typing in the patient's name and then depressing an enter button or“clicking” with a mouse. Existing patients may also be identified byselecting the Find Patient button 612. Similarly, new patients may beentered into the system by typing the patient's name into the data entryboxes 610 and selecting the New Patient button 614. The summary field604 also contains data entry boxes 616 in which the user may identify apatient by a Doctor's medical record number, a hospital identificationnumber, and/or a Pharmacies identification number. Thus, the Platformenables a user to identify a patient using various mechanisms andpreferably utilizes coded numbers to help Doctors/Pharmacists findspecific records more efficiently.

Referring now to FIG. 5, the Platform suitably waits or cycles untileither an existing patient's name is entered or a new patient's name isentered into the data entry boxes 610, 616 as shown in operations 504and 505, respectively. More specifically, in operation 504, the Platformqueries whether the user has entered a patient name. If no patient nameis entered, the Platform proceeds to operation 505 and queries whether asearch for a patient has been requested by the user (preferably via theFind patient button 612) and presents the person search screen (Block507). Further, when a patient's name is entered (i.e., the answer to thequery in operation 504 is “yes”), the Platform determines whether theentered name is a new patient, as shown in operation 506.

When a user enters an existing patient's name into the data entry boxes610 (FIG. 6B), the Platform proceeds with operation 508 and populatesthe data entry boxes for each tab in the detailed information field withinformation obtained from a data storage device 512. Further, for thisembodiment, the user is provided information to which they areauthorized, as determined based upon the previously entered accountnumber and password information.

When a new patient is being entered into the Platform, the user mayselect the New Patient button 614. At this point, the Platform proceedswith presenting the New Patient screen 640, as shown in FIG. 6D. Thisscreen 640 provides various data entry boxes into which the user mayenter the new patient's contact information. Such information may besuitably stored in a database. Once the user selects the Ok button 605,the patient's contact information is entered into a database. Theprocess then proceeds in operation 510 with allowing the user to enterpatient information into the data boxes provided in the detailedinformation fields 606 (FIG. 6B) associated with each of respective tabs608. As discussed previously with relation to existing patients, newpatient information may also be entered via voice directions or othertechniques (for example, scanning or copying and pasting information).

Further, it is anticipated that new patient information will be enteredinto the Platform by a Doctor's support staff when a patient firstvisits the Doctor's office or other medical facility. In one alternativeembodiment, a Doctor's device (such as a PDA) may be equipped with adaily appointment schedule, wherein all of the information needed for aDoctor's routine for a given time period or day is pre-loaded into thePDA, thereby simplifying those actions necessary for the Doctor toaccess patient information and providing immediate access to suchinformation.

Additionally, it is to be appreciated that various other modificationsto the Platform may be provided. For example, a hospital ward mayprovide each nurse with PDAs or similar devices containing preloadedpatient medical information for each patient on the ward.

Referring again to FIGS. 5 and 6B, the Platform also allows a user toidentify a patient by a patient number. More specifically, when anexisting patient is inputted into the data entry boxes 610 and theappropriate button selected, the Platform suitably calls recordsassociated with the patient from a database. Such records are preferablyassociated with the patient via at least one patient identifier, forexample, a Doctor medical record number, a hospital record number, and apharmacy record number. Such identifier may be displayed in the recordfield 616, as shown in FIG. 6B. The patient record number identifier(s)enable authorized users to identify a patient and obtain patientinformation even if the patient is incapacitated and the user does notknow the patient's name.

For example, hospital patients generally wear an identifying band aroundtheir wrist. These bands generally contain a patient's name and anidentification number. Since large hospitals often contain patients withthe same name, the medical record number identifier feature enableshospital personnel and others to quickly identify the patient in acomputerized data base, for example, by scanning a bar code provided onthe wrist band. The Platform may be configured such that it iscompatible with bar code readers, retinal scanners, and otheridentification systems which enable an authorized user to quickly andaccurately obtain information related to a patient.

As mentioned previously, the Platform may also be configured to enable auser to search the database for a patient's information by selecting thefind patient button 612. As shown in the example of FIG. 6C, thePlatform identifies those patients for which the particular user hasbeen given access to the patient's medical records. FIG. 6C illustratesa person search screen 620 which is utilized in the present embodimentto find a patient.

As shown, this screen 620 may include various features for identifyingan existing patient including a data field 622 (which presents a patientlist to which the user is authorized) and an alphabet bar 624 (which,for example, enables a user to identify users by the first letter oftheir last name). Each entry in the data field may be selected byhighlighting and “clicking” on an entry or by highlighting and selectingthe Goto Selected Person button 626. Similarly, in a hands-free or voiceactivated system, a patient might be identified by merely reciting apatient number, a patient's name, a letter of the alphabet at which todisplay a listing of patients, or using other similar techniques.

Further, this screen 620 may also include a search criteria field 628which enables the user to specify how a search for a patient is to beconducted. Drop down menus may be utilized to simplify the specifying ofsearch conditions. A search may be initiated when the user toggles theFind Now button 630. The close button 632 allows the user to exit asearch criteria and the Person Search screen 620 at any time.

For the present embodiment, a combination of look up tables, alphabeticlistings and search criteria may be utilized to identify an existingpatient. However, other identification and look-up techniques may alsobe utilized including those compatible with voice, touch screen, stylus,and other data entry systems. Thus, it is to be appreciated that thePlatform may be configured to utilize various system and methods foridentifying a patient and/or providing any other information to and/orfrom the Platform.

Referring again to FIG. 6B, the Platform may be configured to presentthe summary field 604 at the top of the page regardless of which of thevarious tabs 608 is selected by the user. The summary field 604 maycontains various buttons, such as buttons for View Calendar 613, ViewSummary 615, and Send Instructions 617 (which upon selection instructthe Platform to send treatment regimen instructions to the Device). Whenthe View Summary 615 button is selected, the Platform displays theprescribed medication and treatment regiment, as shown in FIG. 6M. Thisscreen provides summary information about when a patient accessed thevarious features provide by the Device including opening a lid toretrieve a medication and/or accessing instructions programmed into theDevice.

When the patient has been identified to the Platform, the processproceeds according to the various needs of the patient, the user, andthe system. For example, when a new patient is entered into the systemmany of the various data fields accessible by the tabs 608 may need tobe populated with relevant information. Similarly, when an existingpatient (with the system) utilizes a new Doctor or Pharmacist,additional information may need to be entered into the system. Thus, itis to be appreciated that the information illustrated on FIGS. 6B-6L maybe accessed and/or modified by an authorized user as needed and in anysequence as desired, provided an account number, password, and patientidentifier has been provided to the Platform.

When the user of the Platform selects the Care Provider tab 644, thePlatform presents the Care Provider screen 642 (see FIG. 6E) whichprovides (in the detailed information field 606) information pertainingto the identity of the patient's primary care physician, hospitaladmission information, referrals or transfers to another Doctor, andPharmacist information. This data may be populated via varioustechniques, such as, using the Search for Doctor button 607 to find aDoctor from a listing. Such a listing of Doctors may be configured suchthat only those Doctors affiliated with the patient's insurance companyand subscribing to the system are identified for referrals. Similarly,such listings may be provided for hospitals and/or Pharmacists. However,listings based upon any other criteria may be utilized as desired.

Further, this screen 642 may also provide a Consent to Release button645 which, when selected, directs the Platform to display the PatientConsent screen 646, as shown in FIG. 6F. This screen 646 providesinformation, in field 613, relating to privacy provisions of theinformation provided by the patient with regard to the various users ofthe system. The Please Select box 609 allows the user (with the client'sexplicit and/or implicit permission) to select the user to whom accessto the patient information is to be provided (for example, a specialist,a hospital, and/or a Pharmacist) and/or to transfer consent to a thirdparty. As such, the Platform may be configured such that it is compliantwith various privacy regulations and laws by providing opt-in featuresfor the release and dissemination of personal data.

As shown in FIG. 6G, when the Medication tab 634 is selected, thePlatform presents the Medication screen 638. This screen 638 may beconfigured to provide in the detailed information field 606 variousfields, boxes and buttons related to prescribing a medication to apatient. However, it may also be utilized to prescribe non-medicationsto patients and other treatment regimens including vitamins, exercises,and other health related information. More specifically, on this screen638, the Platform provides a Current Medications field 636 in whichcurrent medications/treatments that are prescribed (and have beenidentified to the system) for the patient may be presented. When amedication identified in the field 636 is selected, the Platform maysuitably populate the Rx fields 631 with available prescriptioninformation, for example, the Rx name, generic name, dosage, pill count,number of refills allowed, issue date, date started, expiration date,next refill date, date stopped, and the date last ordered. An RxSupplier button 615 may also be provided. This button 615 enables theuser to access information on the medication that is provided by the RXSupplier. Such information, when available, may be accessed, forexample, via an Internet connection. A field 633 in which a reason forstopping a medication or treatment regimen may also be provided. Such afield 633 preferably informs subsequent users (specifically, Doctorsand/or Pharmacists) as to why a previous prescribed treatment wasterminated.

This screen 638 may also include an Add Rx button 621 which, uponselection, enables the user to enter new prescription information intothe patient's data files. Similarly, old prescriptions can be removedvia the Remove Rx button 623. Lastly, the Voice Record button 617enables the user to record treatments verbally, utilizing readilyavailable voice recognition software.

As mentioned previously, the system may also include interfaces with atleast one medication clearance system to determine whether atreatment/medication is desired for a given patient. The CurrentMedication field 636 provides both a Conflict and an Alert indication asto whether a treatment is contra-indicated. When such a conditionexists, the Platform enables the user to access information indicatingwhy a Conflict or Alert condition exists by selecting the conflictedtreatment and the Review Conflict Notes button 627. Further, when anAlert and/or a Conflict condition exists, the user may view theAlertConflict in the field 635 and/or clear the AlertConflict via theClear button 619.

Additionally, this screen 638 may be configured so as to allow the userto view compliance details, as determined by the Device, by selectingthe View Compliance Details button 625. The Platform may be configuredto display such compliance details in a format preferred by the user forexample, using tables, graphs, and usage charts. One embodiment of howthe Platform includes compliance information is shown in FIG. 60, on theCompliance Summary Screen 681. As shown, this screen 681 may include asummary of compliance information for the patient on a daily basis.

In addition to including an indication of a treatment prescribed to auser, the Platform may include fields in which the timing of thetreatment, dosage, and other variables may be specified, as shown inFIG. 6H. As shown, the Rx Schedule screen 639 is preferably presentedwhen the Rx Schedule tab 637 is selected. This screen 639 may include aGeneral Schedule field 641 in which the user may specify the schedulefor a patient's treatment regimen. A Speak Special Instructions button648 may also be provided which enables the user to specify verbalinstructions for the patient related to a treatment regimen. Asdiscussed previously and in greater detail below, these verbalinstructions may be programmed into the Device for future presentationto the patient. Additionally, this screen 639 provides a Schedule field643 in which a user may view an entered treatment regimen by day of theweek and time of the day. The Clear Schedule button 647 enables the userto quickly reschedule a given treatment regimen.

Referring now to FIG. 61, when the user selects the Notification tab650, the Platform may be configured to present the Notification screen649. This screen desirably includes in the detailed information field606, additional fields for specifying Bottle Controls, Bottle Alerts,Default Settings, and Cap Locking Features 651, 652, 653, and 655,respectively. More specifically, the Bottle Controls field 651 may beconfigured to provide data boxes in which, among other things, the usermay specify variables used to control how the Device (a.k.a., theBottle) functions including: a classification of Rx use; ReminderIndicators; Sound Pitch; Sound Volume; Voice Gender; Reminder Schedule;and Turn Off Reminder After. The precise settings for each of thesefunctions may vary depending upon the particular configuration of Deviceutilized.

Further, the Bottle Alerts field 652 may include various methods fornotifying a patient, via the Device, that it is time for a programmedevent, for example, administering a treatment regimen by consuming aprescription medication. These methods of notifying the patientpreferably include utilizing a vibrating, audio, or visual signal.However, the Device may also be configured to include other perceptibleindicators and is not limited to the preceding indicators.

The Default Settings field 653 enables the user to specify how theDevice is to operate in a default mode. Such settings include whether toTrack Compliance, Check Complications for treatment regimens, enable theLow Battery Indicator, and whether a Label should be printed.

Further, the Review Recorded Messages button 654 enables the user toreview any messages currently recorded for the patient regardless ofwhether such messages have or have not been programmed into the Device.When this button 654 is selected, the Platform displays the MessagesScreen 674, as shown in FIG. 6N. Additionally, this screen 674 can beconfigured to present both generic messages and messages specificallytailored for a specific patient. FIG. 6S provides an illustration of ascheduling screen utilized to identify when messages are to be presentedand also to download Device information by selecting the Download DeviceEvents button 686. When this button 686 is selected, the Platformdisplays the Download screen 689, as shown in FIG. 6T. As shown, thisscreen 689 enables the user (Doctor or Pharmacist) to select thedownload format, time periods, patient, prescription and otherinformation recorded by a Device. Such downloaded information may beutilized to determine compliance, track usage and other functions.

Referring again to FIG. 6S, this screen 685 also enables theDoctor/Pharmacist to download complication information by selecting theDownload Complications Notes button 687. When this button 687 isselected, the Platform suitably displays the Complications Notes screen683, as shown in FIG. 6Q, wherein information on complications ispresented to the user. Similarly, the Review Device Messages button 688enables the user (Doctor/Pharmacist) to review messages programmed intothe Device and edit and remove messages, as shown in FIG. 6N.

As shown in FIG. 6N, the Messages screen 674 also provides a MessagesSelection field 676 in which the user may select a previously recordedmessage to review in the Message Text field 675. Further, this screen674 enables the user to Edit 677 messages, Remove Messages 678, TurnOn/Off 680 the message feature on a given Device, and Speak 679 newmessages.

In alternative embodiment, the Platform may be configured so that apatient can retrieve treatment regimens from the system even if a Deviceis not available. Such feature enables users who forget to take theirDevice with them (for example, on a vacation) to call into the systemand retrieve treatment information. Similarly, this feature enablesDoctors and/or Pharmacies not configured to utilize the system to alsoretrieve treatment regimen information from the system.

The Cap Locking Features field 655 is also provided on this screen 649(FIG. 61). This field 655 is provided for those embodiments of a Devicein which a locking cap mechanism is utilized. It is anticipated thatthis feature, which allows the user to specify when a patient can accessa medication, will be very desirable for patients who have a history ofabusing prescription medications. Similarly, the Review Threshold RxCounts button 656 allows a user to review on the Threshold Rx Countsscreen 684 (as shown in FIG. 6R) medication thresholds that may bepredetermined by Doctors and/or clinical researchers. These thresholdsprovide benchmarks for measurement of dosage and frequency and are oftenutilized to wean patients off of addictive medications or to preventsuch addictions from occurring.

Referring now to FIG. 6J, when the user selects the Case Management tab657, the Platform presents the Case Management screen 658. As shown,this screen 658 provides a Case Management field 659 in which the Doctormay enter information pertaining to the patient's symptoms and/orphysical/medical condition. Upon entry of the any necessary informationthe Doctor, as desired, may access expert systems, third partydatabases, on-line periodicals and tutorials, and other information inorder to determined the cause (if known in the medical community) of thepatient's condition, identify treatment regimens, and access otherinformation.

Additionally, this screen 658 includes the Voice Record Symptoms button660 which enables the Doctor to record the patient's symptoms orally.Such a feature may be desired, for example, when a second opinion isneeded or other consultations are to be performed. Additionally, otherbuttons can be added which enable the Doctor to attach links to datafiles containing, for example, medical image files, test results, labresults, consulting opinions and other information. Thus, variousembodiments of the present invention may be configured to link orotherwise provide any medical information that is can be presented overa communications network.

Further, this screen 658 provides a Special Conditions/Risks field 661,in which the user may enter information relating to the patient'sspecific medical condition. Similarly, a Patient Deficiencies field 662is provided which identifies any physical difficulties the patient mayhave. This information is preferably utilized in programming thetreatment regimen into a Device since, for example, a deaf persongenerally may not desire to receive an audible signal but does desire toalways receive a tactile signal.

The Message Request Statistics button 663 enables the user to determinehow often a patient has requested information from the Device and whattype of information was requested. One example of such statistics isshown in FIG. 6P. These statistics enable Doctors and Pharmacists toidentify problem areas in the patient's use of the Device. For example,a patient who repeatedly requests a given message to be repeated twice,might be doing so because the message was spoken too quickly during theinitial recording and is therefore hard to understand. These statisticscan also provide the Doctor with additional insights into the patient'snon-specified condition (for example, hearing loss, comprehensionchallenges, or other ailments). Additionally, a Non-ComplianceStatistics button 664 is provided and enables the user to determine thepatient's compliance history for a previously prescribed treatmentregimen.

Insurance information for the patient may also be provided to and/oraccessed via the system by selecting the Insurance tab 665. Uponselection of this tab 665, the Platform presents the Insurance screen666 as shown in FIG. 6K. This screen 666 includes an Insuranceinformation field 668 and a Spouse's Insurance Information field 667.Additionally, in alternative embodiments, links to the designatedinsurance provider are provided (for example, via a pull down menu).Such links enable the user to directly contact the insurance providerfor the specific patient.

The Platform also includes a Notes screen 669 which is presented uponselection of the Notes tab 670, as shown in FIG. 6L. On this screen 669,notes previously entered into the Platform (and the patient's data file)may be displayed in the detailed information field 606. Additional notesmay be added by typing the note (via button 672) and/or selecting theVoice Record New Note button 671 and orally presenting a new note whichis then suitably converted to text by voice recognition software. Once anote is entered into the Platform, for one embodiment of the presentinvention, the note is permanently saved and can not be deleted orerased. Other embodiments, however, may not require notes to bepermanently saved. Additionally, the preferred embodiment only allows aDoctor/Pharmacist to enter notes for a given day, and does not allow theDoctor to post-date entries. However, it is to be appreciated that inalternative embodiments, such post-dating and/or modification of notesmay be possible.

As mentioned previously, the Platform includes, in the summary field604, the View Summary button 615. Upon selection of this button 615, thePlatform presents a summary page of the treatment regimen(s) prescribedfor the patient. This summary includes as little or as much informationdesired by the user. FIG. 6M provides an example of such a summary inwhich a Rx schedule for a given patient is provided. Additionally, it isto be appreciated that other time periods may be utilized.

Referring again to FIG. 5A, the process by which a Doctor and or aPharmacist enters and/or obtains the information necessary to identify apatient and then either prescribe a treatment regimen or actuallyprovide a prescription medication to a patient has been described. Sinceonly authorized users are allowed access to the various screens,features and functions of the Platform, the processes by which a Doctorutilizes the Platform and a Pharmacist utilizes the Platform may vary.FIGS. 5B and 5C illustrate embodiments of the processes which may beutilized by Doctors and Pharmacists, respectively, when interfacing withthe Platform after the user and a patient has been identified.

As shown in FIG. 5B, upon identifying the user as a Doctor (Blocks 514and 516) (regardless of whether the patient is new), the process bywhich the Doctor utilizes the Platform preferably continues with theDoctor identifying the patient's symptoms (Block 520). As statedpreviously, the Case Management screen 658 provides data fields in whichthe Doctor can specify the patient's conditions.

The process may then continue with a determination by the Doctor as towhether expert systems and other information for example a Doctordatabase 525 or 3rd party treatment database 527 are to be consulted inorder to assist in the diagnosis of the patient's medical condition. Inshort, the process queries the Doctor as to whether a diagnosis andcourse of treatment for the patient's symptoms is known by the Doctor(Block 522). When the diagnosis is not known, the system may beconfigured to upon request or automatically assist the Doctor withdetermining the cause(s) of the patient's condition and to providerecommendations for a treatment regimen (Block 524).

The process also may be configured to issue queries as to whether amedication is to be prescribed as a part of the treatment regimen (Block526). When a medication is to be prescribed, the process flow continueswith a query as to whether the Doctor knows the desired medication orwhether assistance from an Rx or other database is desired (Block 528).It is to be appreciated that this step commonly will be accomplished bythe Doctor. However, prompts and other querying features may be providedin the Platform as needed and/or desired in specific applications.

If the medication to be prescribed is not known by the Doctor and/or thePlatform itself, the Platform may be directed to access various Rxdatabases (Block 525) to determine which medication(s) to prescribe(Block 529) for the patient's given condition. Further, once themedication has been identified (either by the Doctor or via thePlatform), a dosage is entered and confirmed (Block 530).

At this point, the Platform, preferably automatically but notnecessarily, determines whether the new treatment regimen (which may,but does not have to, include a medication) conflicts with any of thepatient's current or past medications and/or conditions (Block 532). Thesystem may accomplish these conflict checks by accessing a third partyprovided conflicts database (Block 533). When a conflict exists, thePlatform generates an alarm which notifies the Doctor of the conflict.The Doctor may select an alternative treatment (Block 534) by accessing,as necessary, other medical databases (Block 535), and/or overriding anyconflict alarms. For example, when the risk of a conflict is outweighedby the potential benefit of a medical treatment, a Doctor may decide tooverride a conflict alarm. In alternative embodiment, the Platform maybe configured to require the Doctor to enter a note explaining why aconflict is to be overridden, thereby establishing a record of overridesand the rational therefore.

Once any conflicts have been cleared or overridden, if any, the processpreferably continues with a query as to whether a Device has beenpreviously used by the patient (Block 536). If so, the Platform mayobtain compliance information (Block 537) from either the Device itself(if available) or from another Doctor's or Pharmacist's compliancedatabase that is accessible via the Platform (Block 539). Suchcompliance information may be reviewed by the Doctor and corrections inthe treatment regimen, when necessary, may be made (Block 538). It is tobe appreciated, that when substantial changes are made to a treatmentregimen all or part of the process flow of FIG. 5B may need to berepeated, as specified by the Doctor and/or the specific systemconfiguration.

At this point in the process, the Doctor has preferably seen the patientand prescribed a treatment regimen that has been verified as beingacceptable for the patient (or one in which any conflict alarms havebeen overridden). Such treatment regimen may also be entered as a customtherapy into the Platform, if not previously entered (Block 540).

The Doctor may then provide the prescribed treatment regimen to thepatient and/or the patient's Pharmacist (Block 542). Further, anotification may be sent to the Doctor identifying that the Pharmacisthas received the prescription. The Doctor's Platform may also receiveconfirmation from the Pharmacist that the patient has received themedication (when necessary) (Block 544) and such information may beentered manually or automatically into the Doctor's database (Block 546)or a centralized database, as particular needs dictate. At this point,the Doctor's processing is accomplished for a specific patient, andprocessing may then end or proceed with another patient (Block 547-549).

Referring now to FIG. 5A, as shown in Block 518, after the user (who isa Pharmacist) enters an account number and password, and identifies apatient who is requesting the dispensing of a prescribed medication, theprocess flow preferably continues in FIG. 5C at Block 550.

As shown in FIG. 5C, the Pharmacist process continues when thePharmacist receives a prescription for a treatment regimen from apatient directly, via a smart card (as discussed previously herein),from a Doctor electronically (Block 550) or otherwise. At this point,the Platform utilized by the Pharmacist (which may, but does not have tobe, the same Platform utilized by the Doctor) determines whether theprescription is for a new treatment or an old treatment (Block 552). Ifthe treatment is for a new treatment, the process flow continues (Block554) with the Pharmacist's Platform obtaining the treatment regimen fromeither manual input by the Pharmacist, the Doctors' database (Block553), and/or a third party treatment database (Block 555).

When the prescribed treatment regimen is not for a new treatment, theprocess flow may continue with a query as to whether the patient isreturning a Device containing information for a previously prescribedtreatment regimen (Block 556). The determination as to whether a Deviceis being returned by the patient may also be accomplished when a newtreatment regimen and/or a new prescription is being provided by thepatient to the Pharmacist, and/or at other appropriate times.

When a Device is being returned by the patient to the Pharmacist, thePlatform downloads the compliance information from the device (Block558). The compliance information may also be obtained from and/orprovided to the compliance database (Block 559). At this point, adetermination may be made as to whether the compliance information is ofsuch a nature that a Doctor's input is needed before the Pharmacist mayprovide the prescribed medication and/or treatment regimen to thepatient (Block 560). Such a situation may exist, for example, when thepatient is abusing prescription medications.

When a Doctor's input and/or direction may be needed, based upon thecompliance information recorded by the Device, the process flow may beconfigured to enter a wait stage until directions and/or approvals fromthe prescribing Doctor are obtained (Block 561).

Once any compliance information obstacles have been overcome, if any,the processing continues with a query as to whether the prescribedmedication is known to the Pharmacist (Block 562). When the prescribedmedication is not known to the Pharmacist, the Platform may search forand hopefully find information pertaining to the prescription (Block563). Such information may be obtained from internal and/or 3^(rd) partyprescription databases (Block 564), as necessary.

Next, the Pharmacist enters into the Platform the prescription andconfirms the dosage of the medication to be provided to the patient(Block 566). As discussed previously during the discussion of theDoctors phase, the Platform performs a conflict check and determineswhether the new treatment and/or medication regimen conflicts with otherprevious and/or current treatment regimens (Block 568, FIG. 5C1). Inperforming this conflicts check, the Platform uses any availableconflicts databases (Block 569) as necessary. Further, when a conflictarises the Platform instructs the Pharmacist to notify the Doctor andwait for an alternative treatment or medication regimen to be providedby the Doctor (Block 570). However, the Platform preferably does notcreate a conflict alarm when the Doctor has already cleared the sameconflict during the prescribing phase of the process. The notificationto the Doctor may be provided via the Doctors' database(s) (Block 571)and/or via any other communication links.

Once any conflicts have been cleared by the Doctor, the process flowcontinues with the Pharmacist confirming the dosage. Third partydatabases (Block 555) may be utilized (manually or automatically) toconfirm the dosage. It is to be appreciated that while the preferredembodiment utilizes a conflict check at both the time of prescribing bythe Doctor and the time of dispensing by the Pharmacist, that theprocess flow may be configured such that neither and/or both conflictschecks are accomplished.

Once the dosage has been confirmed (Block 572), the Pharmacist is nowready to verify the Device operates correctly (Block 573). ThePharmacists may enter into the Device a custom treatment regimen and/ortherapy to be provided to the patient (Block 574). The treatmentregimen, when it includes a medication, may also be entered into theDevice. The Device may then be provided to the patient (Block 576) orreturned to the patient (when the Device was previously issued to thepatient).

Upon providing the Device to the patient, the Pharmacist desirably mayissue a notification to the Doctor that the prescribed medication hasbeen provided to the patient (Block 578). Similarly, an entry may beautomatically or manually made into the Pharmacist's database of themedication and/or treatment regimen prescribed and dispensed to thepatient (Block 580).

At this point, the prescribing and dispensing of a medication and/or atreatment regimen to the patient is completed. The process may thencontinue with another patient or terminate (Blocks 582, 584 and 586).

As mentioned previously, the patient's Device 206 (as shown in FIG. 2)is another component of various system embodiments of the presentinvention. As discussed previously, the Device may utilize amicroprocessor or micro-controller to control the notification featuresand various other functions of the Device. More specifically, themicroprocessor may utilize code processes which are stored in the memorystorage device 406 (FIG. 4). These several coded processes allow theDevice to receive information for up to eight (8) differentprescriptions from a host connected to a docking station or otherinterface device. In various other embodiments, more than eightprescriptions or treatment regimens may also be received. Further, thedocking station is typically located at a Pharmacist's office and/or aDoctor's office.

These and/or other coded processes control the various functions of theDevice and may utilize information downloaded from the Platform toprovide the desired instruction to the patient. The downloadedinformation may include treatment schedules, drug prescription anddosage information, general messages regarding Pharmacist and/or Doctorcontact information, service notification information, Device relatedstatus information, and/or other information. These coded processespreferably can also return information pertaining to the patient'scompliance with a treatment regimen and/or Device status information.

When the Device is initialized, for example, after having received a newtreatment regimen from a Pharmacist, the various registers, counters,I/O controllers, speech synthesizer, and other components areconfigured. When these and other components of the Device areconfigured, the configuration information may be routed, as necessary,to the main operating system of the Device (i.e., the main controlloop).

In at least one embodiment, the main control loop may be configured toperform a series of actions that evaluate the condition of the Device'svarious components, schedules, and interfaces, for example, the pushbutton. The main control loop may also direct the performance of varioussub-services including, but not limited to, evaluating link wake-up andpower mode status, reading and qualifying a current time, evaluating thestatus of the various buttons provided on the Device (i.e., whether apatient has depressed the button), call finding and active messagingroutines, and performing various other status and maintenance tasks.

More specifically, the main control loop may control the sub-serviceresponsible for establishing, maintaining, and monitoring thosecommunications links necessary to transmit information between theDevice and the Platform. These processes may include reading andinterpreting command requests, sequencing multi-byte message texts, andproviding schedule changes to the Device. Such information may bedirected, by a sub-service, to appropriate locations in the memorystorage device. Further, a sub-service may control the passing ofinformation between the Device and the time keeping chip and between thetime keeping chip and the docking station (for example, when aclock/timing synchronization routine is being accomplished).

The main control loop may also facilitate the passing of prescriptionand/or treatment regimen schedules to the Device over the communicationslink provided between a pharmacy's Platform and the Device. Theprescription schedule information may be provided in a seven day,twenty-four hour format, which generally results in twenty-one bytes ofschedule data per each prescribed treatment regiment. However, otherformats may also be utilized by the Device. The Device may also beconfigured to save schedule information, for example, in fixed memorylocations which may be pre-allocated in the memory storage device 406.In the preferred embodiment, each prescription schedule is allocatedthirty-two bytes of memory. However, larger prescription schedules maybe provided when larger memory storage devices are utilized.

Additionally, the main control loop may utilize an events schedulersub-service to periodically take readings from the internal clock andevaluate whether a treatment regimen event time has arisen, as indicatedin a treatment index. More specifically, upon the changing of each hourof a day (or another designated time interval of longer or shorterduration), the events scheduler may be configured to save any unopenedprescription status information, format and then compare the currenthour and day index to each of the active prescription schedules loadedin the Device, and determine whether an event time has arisen. Further,the events scheduler suitably flags, in the memory storage device, anycurrently due treatment regimens and returns operations to the maincontrol loop.

Another sub-service process which may be provided in conjunction withthe main control loop is the memory storage read/write service. For atleast one embodiment, the memory storage device provides 32K by 8 bytesof non-volatile memory which may be accessed over a common two wireserial protocol. The memory storage device read/write service enables auser of a Device (for example, a Pharmacist or a Doctor using a thePlatform connected to a docking station) to read and or write specificdata to the various data storage locations provided by the memorystorage device. In this manner, the user of the Device can access and/orprovide specific information pertaining to the patient's compliance withthe treatment regimen, treatment regimen instructions, the operation ofthe Device, and other information.

Another sub-service which may be provided by the main control loop isthe momentary button process service. This sub-service provides buttonrelated interrupt event status and messages to a patient based upon thedepressing and/or momentary holding of the button. More specifically,this service may utilize coded sequences to call a message schedulerthat may be configured to maintain sequences of treatment regimeninstructions, Device status messages, and other information. Further,this service may provide various button condition indicators including,but not limited to, determining when a double momentary depressing ofthe button occurs, whether the button has been depressed for a specifictime interval, and other button functions as discussed further herein.The operation of the button processes is described in greater detailwith reference to FIGS. 7, 10 and 11.

Another sub-service provided by the main control loop is the synthesizerscheduler service. The synthesizer scheduler service stores treatmentregimen instructions in the memory storage devices and utilizes anindexing system based upon a first byte of an instruction string messageto assign a start location in the memory storage device of theinstruction message. Utilizing this indexing scheme, variable lengthtreatment regimen instruction messages may be utilized without wastingstorage space in the memory storage device. Such instructions may bespecifically tailored to a patient and/or pre-canned instructionsobtained, for example, from a third party database.

When the time arises for an instruction message to be communicated tothe patient, the main control loop may be configured to identify thelocation of the desired instruction message by accessing the previouslyestablished index. Thus, each message that is to be presented to thepatient by the Device to the patient may be saved in the memory storagedevice and the first byte may be indexed. By utilizing this format ofmessage pointers and variable link messages, the Device may beconfigured with a fixed linked memory storage Device of 96 bytes. Thisconfiguration allows up to 43 messages for both the general and eachprescription specific message to be stored and accessed by the Device.

Referring now to FIG. 7, one embodiment of the process flow of the maincontrol loop is illustrated. As shown, the process flow begins when astart and/or power on sequence occurs (Block 700). At this point, themain control loop initializes the hardware, as previously discussed,including the interface ports, smart cards interface portal, buttons,visual displays, cap sensors, cap solenoids, speakers, clocks,vibrators, storage devices and speech synthesizer, as necessary (Block702). The process then determines whether a treatment regimen has beenloaded into the memory storage device (Block 704).

If a treatment regimen has not been loaded, the Device establishes acommunications link with a Platform provided by either a Pharmacist or aDoctor and loads a treatment regimen into the Device (Block 705), once atreatment regimen is available for programming into the Device. Oneembodiment of the process by which the Device establishes acommunications link and loads a treatment regimen is further describedwith reference to FIG. 8.

As shown in FIG. 8, one embodiment of the process by which the Deviceloads a treatment regimen begins with a power on event (Block 800). Atthis point, the Device enables/activates the interface port (forexample, an infrared port, Block 802) and/or the smart card reader (whenprovided). After enabling the interface port, the Device then waits onesecond for the communications link between the Platform and the Deviceto be established (Block 804). As discussed previously, the Platform mayutilize a docking station to interface with the Device. If a responsefrom the Platform (i.e., the host), does not occur within thepre-determined time interval, preferably one second, an audible alarm issounded by the Device (as shown in Blocks 806 and 808).

When a response is received from the Platform, the Device reads a datapacket provided by the Platform, i.e. the host, (Block 810). This datapacket (which may include a treatment regimen instruction) is suitablystored in the memory storage device contained in the Device (Block 812).After receiving a full data packet, the Device determines whether thelast packet has been received (Block 814). If the last packet has notbeen received, the Device repeats the reading of the data packets fromthe host and the storing of the data packets in the memory storagedevice until the last data packet has been received and stored (Blocks810 and 812). At this point, the Device returns to the main control loopas shown (Block 816) in FIG. 7 at Block 706.

After the Device has been loaded with the treatment regimen, the maincontrol loop continues with issuing a query as to whether a scheduledevent, as defined by the treatment regimen (or as defined by theinternal maintenance procedures associated with the Device) has occurred(Block 706). When a processed scheduled event time occurs, the Devicesuitably processes the event utilizing the process shown in FIG. 9(Block 708).

As shown in FIG. 9, upon receiving a power on or other sequence for theDevice to process a scheduled event (Block 900), the processing checksthe current time (Block 901) and then determines whether a scheduledevent, such as a time for taking a medication, has arisen (Block 902).When a time for taking a medication has arisen, the scheduled eventprocessing routine proceeds with speaking or otherwise suitablyproviding the first medication and/or treatment regimen message to thepatient (Block 904). When configured, the processing may also turn onthe vibrator for a predetermined time period (preferably two seconds)(Block 906) and may activate the yellow LED light (Block 908), and/orany other functions specified during the prescribing of the treatmentregimen.

When the patient does not respond to the message, vibration and/or greenlight (i.e., the patient does not access a medication from the Device orotherwise acknowledges the message) within the predefined time limit,the process scheduled event routine continues with issuing a firstwarning (Block 903).—The process then provides a message to the patient(which may include all or part of the previous message in addition toother instructions) (Block 905). The process may also reactivate thevibrator (Block 907) and/or the yellow LED light (Block 909).

Similarly, when the patient does not respond to the first warning withina predefined time limit, the process scheduled event routine continueswith issuing a second warning (Block 910). Similar to the first warning,the second warning includes the functions of speaking or otherwisesuitably communicating the first medication message and/or othermessages to the patient (Block 912), turning on the vibrator for apredetermined time period (Block 914), and/or turning on a red LED light(Block 916). If the patient has not responded to either of the processscheduled event warnings, the Device returns to the main control loopand determines whether a button has been pressed (Block 918), as shownin Block 710 of FIG. 7.

When a button has been pressed, the main control loop implements theprocess button press routine (Block 712). As shown in FIG. 10, theprocess button press routine begins (Block 1000) with a determination asto whether a button was depressed for a one second interval (Block1002). When a button is depressed for a one second interval, the Deviceproceeds with communicating to the patient the medication schedule.Additionally, the Device utilizes the internal clock and the savedmedication schedule to determine whether the button was pressed before,during or after a scheduled medication or treatment regime is to beprovided (Block 1004). If the button is depressed for one second beforea scheduled medication is to be provided, the pre-recorded messageprovided by the Doctor relating to activities the patient is to performprior to his scheduled medication time is preferably communicated by theDevice to the patient (Block 1006). Similarly, if the button is pressedfor a one second interval during a treatment regimen time, instructionsare provided to the patient specifically geared towards the takingand/or administering the treatment regimen (Block 1008). Further, if thebutton is pressed for a one second interval after a scheduled treatmentor medication regimen has been administered, the Device communicatesinstructions provided by the Doctor for the patient to accomplish afterthe taking of the treatment regimen (Block 1010).

When the button is depressed and held for a two second interval (Block1012), for example, in response to a notification that it is time forthe patient to administer a medication and/or a treatment regimen, theprocess button press routine preferably continues with providingconflicts, warning and treatment regimen information (Block 1014).

Further, when the button is pressed and held for a four second interval(Block 1018), the Device provides an indication of the battery powerlevel (Block 1020). The battery level indication may include a textmessage, LED lights, and when equipped with a visual display, an Icon orsimilar indicator of the battery power status.

Lastly, when the button is double pressed (Block 1022), the Devicecommunicates contact information, for example, addresses and/or phonenumbers of Doctors and/or Pharmacists associated with the prescribedtreatment regimen (Block 1024). At this point, the processing returns tothe main control loop as shown in FIG. 7. Upon which instance, the maincontrol loop performs a timed delay and resumes processing (Block 714).While one embodiment of the present invention is described above asproviding specific functions based upon specific presses of a button orother input signal, it is to be appreciated that the present inventionis not limited to any specific input devices, input sequences, buttonsequences or the like and that the present invention may providedifferent functions for different embodiments of the present inventionand that such different functions may be in response to receiving aninput signal via methods other than pressing a button.

As shown in FIG. 11, an embodiment of a process by which a patientutilizes the Device to receive a treatment regimen and/or a prescribedmedication is depicted. As shown, this process begins when a patient isseen by a Doctor (Block 1102). During the visit by the patient with theDoctor, the Doctor commonly will prescribe a treatment regimen which thepatient may have filled and/or dispensed by a Pharmacist utilizing aDevice (Block 1104). Thus, at this stage of the process, the Doctorand/or the Pharmacist have utilized any treatment clearance systemsnecessary and prescribed a treatment regimen which is designed toaddress the patient's medical condition. This treatment regimengenerally includes instructions programmed into the Device, wherein theinstructions direct the patient as to how, when, why and where to take aprescribed treatment regimen which may or may not include a prescriptionmedication.

In order to maximize the benefits of utilizing the Device to provideinstructions related to a treatment regimen, the patient may carry theDevice with them at all times. However, it is to be appreciated that theDevice may be configured as a stand-alone unit which is placed in alocation accessible to the patient (Block 1106).

When the patient receives and activates a Device, the process maycontinue with the patient observing the operating status of the Device(including pre-recorded treatment instructions) and/or waiting for anotification signal to occur, before the Device takes any further action(Block 1108). As discussed earlier in relation to the main control loop,the Device may be configured to wait for the time at which a treatmentevent is scheduled to occur. Until such an event time arises, the Devicemay query itself as to whether the current time is the designed time fora treatment regimen (Block 1110).

However, the Device does allow the patient to check if the Device isfunctioning properly by pressing and holding buttons for four seconds,as discussed previously (Block 1112). When the Device is functioningcorrectly, text messages, audible sound, tactile, and/or visualindicating signals are generated by the Device. If some or allindicating signals are not being correctly generated by the Device, thepatient should contact the Pharmacist or Doctor and/or return the Deviceto the issuer (Blocks 1114 and 1116). Additionally, when the Device isfunctioning properly, the processing continues with the Devicetransmitting an appropriate notification signal to the patient (Block1118).

When the time for a treatment regimen occurs (Block 1110), anotification signal is provided by the Device to the patient (Block1118). As discussed previously, the notification signal may include avisual signal, for example, a blinking LED light. Further, it is to beappreciated that various other types of identification signals,including vibrations and audible signals, may be utilized by the Deviceto notify a patient when a time has arisen for a prescribed treatmentregimen and/or to notify the patient of the Device status. Upon receiptof the notification signal, the patient may check the primary message bypressing and releasing the “talk” button, i.e., a press and releasefunction (Block 1120). Generally, a simple press and release of thebutton by the patient will instruct the Device to provide sufficientinformation for the patient to understand the actions necessary to betaken by the patient in conjunction with the prescribed treatmentregimen. However, if the patient does need additional information (Block1122), the patient may suitably check other messages by pressing and/orholding the button for various time periods, as discussed previously(Block 1124).

Upon receiving all necessary instructions, the patient takes themedication, and the Device records the compliance information in itsinternal memory storage device. This process flow continues until thepatient either finishes the prescribed medication treatment regimen or arefill is needed (Block 1126).

Referring now to FIGS. 12A-12×, an exemplary series of screen shots ofthe Platform are provided which illustrate how a Doctor and/or aPharmacist may interface with another embodiment of the Platform inorder to prescribe a treatment regimen and verify the prescribedtreatment is not contra-indicated for the patient. As shown, thisembodiment of the exemplary series of screen shots are provided by theRxSure™ program. However, other programs, screen shots, and processflows may be utilized without departing from the spirit or scope of thepresent invention.

As shown in FIG. 12A, the process, by which a Doctor, a Pharmacist or anAdministrator (desiring to add, review, modify, transfer or deletepatient records, etc.) interacts with the Platform, begins through anintroductory screen 1200 that is used to select a professional's servicelevel 1202 to the specific contents and/or functions of the Platform.Such service levels include access to the content information thatrelates specifically to the role of the given professional and the tasksthey are to perform. One possible means of access to such service levelswithin Platform is granted based on the successful input, matching andconfirmation of pre-programmed security access codes when the Doctor,Pharmacists or Administrator logs onto the Platform as shown on asubsequent access screen 1204 as shown in FIG. 12B.

Security access codes can be an important feature for restricting accessto information stored on the Platform and/or functions provided by thePlatform, especially in terms of patient confidentiality. Multiplesecurity levels also have a time-saving benefits because differentprofessionals are focused on specific aspects of patient care andgenerally prefer not spending time searching through all the informationstored on the Platform in order to find and address a pertinent issue ora task at hand. In addition, security levels can be used to monitor theactions of a given group to ensure that the professionals aremaintaining desires standards of performance. Such means of monitoringincludes, but is not limited to, the tracking of specific actions (forexample: menu selections, changes in prescription dosages, typed orrecorded notations, etc.) made by a Doctor, Pharmacist or Administratorwhile interacting with the Platform.

An exemplary set of security access levels, that may be used to limit aDoctor, a Pharmacist or an Administrator's ability to interact withstored information on the Platform, is shown in FIG. 12C. A content tabreference screen 1206 illustrates one such possible grouping of menuscreen tabs. More specifically, a level one security grouping 1208refers to a lower level security ranking that is normally accessed by anAdministrator charged with tasks such as retrieving, entering, orupdating patient records on the Platform. Such content relates to thegeneral background information on a new or existing patient. A level twosecurity grouping 1210 refers to a higher level security ranking that isnormally accessed by a Doctor or Pharmacist charged with tasks such asprescribing, monitoring, or updating patient regimen information storedon the Platform. A security level three grouping 1211 refers to yet aneven higher level security ranking that is normally accessed by anAdministrator charged with system-related tasks such as programming,monitoring, or updating the operation of the Platform and its content. Afurther breakdown of this level reveals two possible menu tabs. One suchmenu tab is a linkage tab 1212 that functions in the same manner as anaccounting audit trail, whereby an Administrator can specify whatchanges have occurred to the Platform's content from a given date aswell as track what information is to be captured and stored within thehardware device in a permanent fashion. Another such menu tab is anarchive tab 1214 that displays the permanent notation of all contentchanges to the Platform and/or the hardware device that took place onany given day since one or more corresponding tracking features wereactivated on the linkage tab 1212. Although screen 1206 only identifiesthree such security groupings, other levels can be added, combined orremoved to suit the specific needs of the users.

Referring now to FIG. 12D, a content screen 1215 is shown thatidentifies the menu tabs associated with level one security ranking, andis normally associated with an Administrator who deals with generalbackground information about a given patient. Such tabs include ContactInfo, Care Providers and Insurance facts but could include other menutabs, such as medication, that are entered by the Administrator andprovide more detailed information about the patient's past or currentlist of medications. All other tabs remain hidden from the Administratorbased upon the assigned user access level that was entered in the accessscreen 1204 as shown in FIG. 12B.

FIG. 12E illustrates an alternative layout of a Patient Info screen 1216whereby the Consent to Release button 645 has been relocated from theCare Providers tab 644. Such a layout change may prove more intuitivefor the user of the Platform who must secure an authorized consent fromeach patient as part of their required patient information profile.Also, a screen segment 1217 titled Emergency Contacts has been isolatedfrom the other fields and shown with its own set of internal tabs inorder to highlight situations where it is beneficial or appropriate toprovide multiple contacts and a certain medical specialist for a givenpatient.

FIG. 12F provides an alternative layout of a Care Providers screen 1218whereby the release or transfer of information section has been expandedto include a Transfer Rx to another Pharmacist/Store 1220. Such anaddition may prove a time savings element whereby a given prescriptioncan be sent electronically through the Platform to a designationlocation without the need for a telephone call by the Doctor or thepatient. As patients visit relatives, vacation, temporarily orpermanently relocate, or find more cost-effective sources for theirprescription, this feature allows the change to be processed withoutdelays or the need for a new signature by the prescribing physician.

FIG. 12G provides an alternative layout of an Insurance screen 1222whereby additional information is provided for a more complete profileof the patient. In particular, a Contact Information section 1223 hasbeen broken out from the original Insurance information field 668 (seeFIG. 6) to distinguish policy details from the information related to aparticular agent. The latter information has the likelihood of changeduring the life of the coverage. In addition to making it easier for theuser of the Platform to find information related to the contact theagent, this alternative layout reflects a separation of data that islikely to change during the life of the particular insurance coverage.Also, a Co-Pay/Deductible section 1224 may include information that isvaluable to the Doctor, Pharmacist and/or Administrator who needs anaccessible record of co-pay fees that must be collected from the patientat the time of the visit or the amount of the coverage deductible priorto sending out an invoice for services received. A breakdown of thedifferent types of co-payments or deductibles includes, but is notlimited to, medical, dental, vision, or prescription drug services orgoods.

A level two security ranking is normally assigned to Doctors andPharmacists. As shown in FIG. 12H, such ranking calls for a set ofcontent menu tabs 1227 that are further defined in terms of a taskingfunction tab 1228 or a forwarding tab 1229. A content screen 1226 isshown that identifies the primary function performed by Doctors andPharmacists. The tasking function tabs 1228 include, but are not limitedto, Medication, Rx Schedules, Case Management, and Message Exchangetabs. The forwarding level tabs 1229 include, but are not limited to,Additional Patient Info and Additional Device Info tabs. Morespecifically, the forwarding level tabs 1229 have the functionalcapability to display other content menus, such as the security grouping1208 for patient background information, that may be of assistance tothe Doctor or Pharmacist. All other tabs remain hidden from the Doctoror Pharmacist based upon the assigned user access level that was enteredinto the screen shown in FIG. 12B.

One of the primary screens used by Doctors involves the prescribing ofmedications. FIG. 121 provides an alternative layout of a Medicationscreen 1230. This layout provides sufficient space for the Doctor orPharmacist to enter and review the typed or voice recorded messageassociated with the current medication to be taken. Such typed or voicerecorded messages include a text space for a Primary Regimen 1231, aCustom Greeting 1232, and a Usage/Warning 1234. The Custom Greeting textspace 1232 is considered a supplemental message that is attached to andimmediately precedes the spoken message content of the Primary Regimenactivated by a single push of the Talk button 318 on the hardwaredevice. The Usage/Warning text space 1234 reveals the content of themessage that will be spoken by the hardware device when activated bypressing and holding the Talk button 318 on the hardware device for 2seconds. The purpose of displaying such message content is to providethe Doctor or Pharmacist with the means to quickly review and confirmthe spoken instructions delivered by the hardware device in conjunctionwith the prescribed medication.

Once the medication has been selected by the Doctor, FIG. 12J providesan alternative layout of an Rx Schedule screen 1236 whereby all contentrelates specifically to the scheduling of a medication rather thanincluding any dosing-related information such as amount, pill color orform, and meal or special instructions as shown in FIG. 6H. Similarly,the field 633 in which a reason for stopping a medication or treatmentregimen has been relocated from the Medication tab 634 in order toemphasize the date and a reason why a particular medication schedule hasbeen discontinued. Another scheduling distinction is created by the useof a Scheduling Shortcuts section 1237 that allows the Doctor to quicklyspecify the generalized medication regimen using three pull-down menusrather than selecting specific times for each specific day. Thesepull-down menus are directly linked to the specific schedule based onthe Doctor entering a starting location. An example of the use of ageneralized schedule is where a Doctor selects “4 times a day” from theday menu, then “every day” beginning “Tuesday” from the week menu, andfinally a duration lasting “60 days” from the monthly pull-down menu.Such a shortcut process is further simplified if the “start” and “end”dates are provided when the medication is specified.

One time saving element for the Doctor relates to the inclusion of afield for pertinent notes about a given patient. FIG. 12K provides analternative layout of a Case Management screen 1238 that includes aMedical Diagnosis note section 1240. This note section allows thePlatform to receive either typed or voice recorded notations andassociate them with the entry date. Should Doctors (primary, secondaryor referred specialist) or Pharmacists need to review the case of a newor existing patient, all diagnosis details are available in one locationand organized by a data stamp. Yet another time saving element is a Linkto Device button 1242. This button serves to link patient deficienciessuch as hearing or visually impaired with the operations of notificationfeatures (i.e., flashing lights, vibrations or audio signals) on thehardware device. In other words, a single menu selection indicating thatthe patient is blind will turn off the flashing LEDs 310 if the Link toDevice button is pressed. Confirmation of a linkage between patientdeficiencies and notification signals emitted by the hardware deviceappears on a Device Control screen 1247 with a Device Alerts section1248 as shown in FIG. 12M.

One of the elements associated with this embodiment of the Platforminterfaces include, but are not limited to, the ability of the Platformto record and disseminate customized instructions for the patient, theinteraction between users on the Platform, and the integration of thePlatform with the hardware device. An sample menu screen 1243illustrating these elements for a Pharmacist is shown in FIG. 12L. Inparticular, customized instructions from a Doctor can be found in a setof function tabs 1244; interaction between users of the Platform callsfor a set of communication tabs 1245 which have been labeled as MessageExchange and Device Controls, and integration of the hardware with thePlatform as indicated by a feedback tab 1246, that is also referred toas Patient Statistics. Also, it is important to note that thecommunication tabs 1245 can include functions such as an electronic mailsystem or instructions from the Platform that are used to program thehardware device. The feedback tab 1246 may provide statisticalinformation that has been recorded based on actions of the patient(i.e., button presses) and available for downloading from the hardwaredevice to the Platform upon its return for a refill or new prescriptioninstructions.

Recalling FIG. 12M, the content screen 1247 illustrates the features ofthe Device Controls tab. In general, these features are used to programthe hardware device, monitor operations, generate statistics, and allowstored information to be downloaded back to the Platform. A sample setof Default Settings 1249 is shown. These settings can be checked orunchecked to allow the corresponding operation to be performed, recordedand/or printed.

Referring now to FIG. 12N, a content screen 1250 illustrates theimportant features of an electronic messaging system between the varioususers of the Platform. Specifically, a user can search, identify anddistribute a customized message inserted into the Message field 1254 toa particular receiver(s) using a Routing Information pathway 1251. Suchmessages can range from, but are not limited to, requests to review aspecific alert to notifications of dosage problems to personalizedcomments about a patient that is being transferred. A Status section1252 is included to help the receiver classify and/or prioritize thepertinent message received. Such status indicators are attached to themessage in order to provide the receiver with a relative level ofimportance associated with a given message and/or the need for acorresponding action in response to the given message.

Pharmacists may play a key role in monitoring a patient's compliance toa given regimen as they are charged with dispensing new medication orproviding refills of an existing prescription. Referring to a contentscreen 1260 in FIG. 120, this monitoring process calls for the use of aseries of display formats 1262 viewed on the Patient Statistics tabwhich are generated by the hardware device in accordance with thepatient's actions (i.e., Talk Button presses). In particular, FIG. 120shows the Regimen Count Summary display which breaks down thetime-stamped button presses (i.e., notification of a medication due andconfirmation that a medication was taken) into actual counts per segmentwithin a 24-hour period. The contents of such a table may beautomatically filled with the statistics that were downloaded from thehardware device to the Platform upon its return from the patient usingcoded routines, algorithms and standard formulas. Should otherstatistics be desired, a Download section 1264 uses activation fields toretrieve the corresponding display format that appears on the samePatient Statistics tab. These fields include, but are not limited to,Regimen Counts, Message Requests, Notification, Confirmation, SurveyResults, and Archives.

FIG. 12P illustrates a content statistical display 1266 for MessageRequests. This display is activated by pressing the corresponding fieldwithin the Download section 1264 of the Platform and is associated withthe Patient Statistics tab. Although similar to the Regimen CountSummary from FIG. 120, this table desirably shown how well a patient isable to understands a spoken message based on the number of times thepressing of the Talk Button is repeated. It may also be used tocalculate the response time of the patient based on the timedifferential between a pre-programmed notification signal and thecorresponding press to hear the spoken instructions. As before, thecontents of such a table my be automatically filled with the statisticsthat were downloaded from the hardware device to the Platform upon itsreturn from the patient using coded routines, algorithms and standardformulas.

FIG. 12Q illustrates a content statistical display 1268 for ConfirmationSummary. This display is activated by pressing the corresponding fieldwithin the Download section 1264 of the Platform and is associated withthe Patient Statistics tab. The purpose of this table is to determinehow often a patient is compliant with a prescribed regimen. Thestatistical display 1268 for Confirmation Summary calls for the use of asecond button located on the hardware device that is activated by thepatient to confirm that the medication was taken after being notified byone or more sensory based notification signals or the spokeninstructions. The Confirmation Button may be green in color and squarein shape in contrast to the Talk Button which may be red in color andround in shape. Although the Confirmation Button is not shown in afigure for this application, it may be used as a “yes” or “no” recordingmechanism based on a pre-defined set of press combinations. Such aconfirmation button is beneficial for a hardware device that merelyinforms the patient of a prescribed regimen but does not dispense anyactual mediation from within the device. This button, pressed inpre-defined combinations or in conjunction with the Talk Button, may beused to calculate the patient's response time based on the differentialbetween a pre-programmed notification signal and the corresponding pressto hear the spoken instructions. It can also be used indicate apatient's understanding of a given alert mechanism. As before, thecontents of such a table may be automatically filled with the statisticsthat were downloaded from the hardware device to the Platform upon itsreturn from the patient using coded routines, algorithms and standardformulas.

FIG. 12R illustrates a content statistical display 1270 for the SurveyResults Summary. This display is activated by pressing the correspondingfield within the Download section 1264 of the Platform and is associatedwith the Patient Statistics tab. The purpose of this table is to displaythe results of a programmed survey (an example of which is shown in FIG.12X) whose results are determined by a pre-defined press combination ofthe Confirmation Button. As before, the contents of such a table may beautomatically filled with the statistics that were downloaded from thehardware device to the Platform upon its return from the patient usingcoded routines, algorithms and standard formulas.

In addition to Pharmacists, Doctors and Administrators may have a needor desire to review a particular set of generated statistics relating toa given patient. These situations are made possible through the use ofproper access codes that display the appropriate content tabs. Again, toemphasize Platform flexibility, any pre-established content tabsdisplayed for a particular recipient can be changed by the systemAdministrators and tracked for future reference.

Two remaining content tabs may be used to cross-reference the actionstaken by different users of the Platform. A Linkage tab 1272, shown inFIG. 12S, and an Archives tab 1276, shown in FIG. 12T, may be usedtogether or separately to create a permanent historical record. Thecontent of the historical record may be determined by checking desireditems from a Recorded History section 1274 on the Linkage tab. Whenactivated, all changes made to a patient's record associated with thechecked field are permanently entered into a notation section with acorresponding date stamp that can be searched by a specific date, aselected date range or a keyword/phrase search. Such records remainpermanent even if the decision to check a given criteria is reversed ata later time. In similar fashion, a Dispenser Tracking section 1273,shown in FIG. 12S, instructs the hardware device as to which items willbe tracked.

Several administrative functions, with separate callout tabs, helpfacilitate processes including, but are not limited to, organizinginformation into tables or displays, coordinating databases,establishing speech parameters, listing or summarizing general andspecific messages, and providing means to enter unique messages. In FIG.12U, an administrative tab 1278 titled “General Messages” illustrates amethod of organizing the general messages spoken by the hardware device.Each entry can be edited by typing or voice recording a selected messagefor pre-programmed insertion into a spoken announcement. In FIG. 12V, anadministrative tab 1280 titled “Rx Messages” illustrates the ability toprovide an additional text or voice recorded message that correspondswith a selected “General Message” from FIG. 12U. In FIG. 12W, anadministrative tab 1284 titled “Red Button Messages” provides the user(typically the system Administrator) with the resulting display of thecombined “General Message” and “Specific Message” text that will beoutputted by the hardware device. In FIG. 12X, an administrative tab1288 titled “Green Button Messages” illustrates the ability to design acustom survey spoken by the hardware device. Such a survey may utilize“Yes/No”, “True/False”, or “Multiple Choice” answers based on the presscombination of the green Confirmation Button. Again, the questions, aswell as pre-defined answers to the questions, can be entered by typingthe text or voice recorded.

Therefore, as discussed previously herein, the present inventionprovides a system and a process which facilitates the provisioning ofspecific and individualized instructions to a patient for a treatmentregimen. While the present invention has been described in the contextof a system and a process it is to be appreciated that the presentinvention is not limited to the systems and/or processes identifiedherein and may be modified as individual applications dictate and/orspecific embodiments require.

1. A method for tracking a medical treatment regimen, comprising theoperations of: receiving, by an electronic device, medical data relatingto a patient's medical treatment regimen; outputting, by the electronicdevice, at least one reminder to comply with the medical treatmentregimen; monitoring, by the electronic device, the patient's compliancewith the medical treatment regimen; storing, by the electronic device,compliance data related to the patient's compliance with the medicaltreatment regimen; and providing the compliance data from the electronicdevice to a medical professional.
 2. The method of claim 1, furthercomprising: receiving at least one instruction to modify at least one ofthe medical data and the at least one reminder; and in response thereto,modifying at least one of the medical data and the at least onereminder.
 3. The method of claim 2, wherein the operation of modifyingat least one of the medical data and the at least one reminder is atleast partially based on the compliance data.
 4. The method of claim 2,wherein the operation of providing the compliance data from theelectronic device to a medical professional comprises providing thecompliance data to a location remote from the electronic device.
 5. Themethod of claim 4, wherein the operation of receiving at least oneinstruction to modify at least one of the medical data and the at leastone reminder is provided from a location remote to the electronicdevice.
 6. The method of claim 5, wherein the operation of receiving atleast one instruction to modify at least one of the medical data isexecuted across a secure communications channel.
 7. The method of claim5, further comprising the operation of accessing, by the electronicdevice, external medical research data from at least third one partymedical information provider.
 8. A method of administering a medicaldatabase, comprising the operations of: accessing a medical database;inputting medical data including at least one of a patient informationor a pharmaceutical information; inputting a patient treatment regimen;reviewing patient compliance data related to the patient treatmentregimen, said patient compliance data provided to the medical databasefrom an electronic device located remotely to the medical database; andmodifying the patient treatment regimen based at least partially on thepatient compliance.
 9. The method of claim 8, wherein the electronicdevice comprises a hardware device, comprising: an input element forreceiving the patient treatment regimen; and an output element forcommunicating the patient compliance data to the medical database. 10.The method of claim 9, wherein the electronic device further comprises:a reminder element for issuing at least one reminder to the patient tocomply with the patient treatment regimen; an acknowledgement element togenerate the patient compliance data.
 11. The method of claim 10,further comprising: issuing the at least one reminder from the reminderelement; receiving, via the acknowledgement element, an acknowledgementof compliance with the reminder; and storing the acknowledgement aspatient compliance data.
 12. The method of claim 11, wherein theacknowledgement is generated by the patient.
 13. The method of claim 11,wherein the acknowledgement is generated automatically by the electronicdevice.
 14. The method of claim 13, wherein the acknowledgement isgenerated automatically by the electronic device in response to apatient interaction with the electronic device.
 15. The method of claim11, wherein the operation of modifying the patient treatment regimenbased at least partially on the patient compliance comprises remotelydownloading, to the electronic device, a modification to the patienttreatment regimen from the medical database.
 16. The method of claim 15,wherein the operation of modifying the patient treatment regimen occursautomatically upon receipt of the patient compliance data by the medicaldatabase.